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Abstract 


The paper introduces a new modular action language, A£M, and illustrates the method¬ 


ology of its use. It is based on the approach of Gelfond and Lifschitz (1993 1998 \ in 


which a high-level action language is used as a front end for a logic programming system 
description. The resulting logic programming representation is used to perform various 
computational tasks. The methodology based on existing action languages works well for 
small and even medium size systems, but is not meant to deal with larger systems that 
require structuring of knowledge. A£A4 is meant to remedy this problem. Structuring of 
knowledge in ACM is supported by the concepts of module (a formal description of a 
specific piece of knowledge packaged as a unit), module hierarchy, and library, and by the 
division of a system description of ACM into two parts: theory and structure. A theory 
consists of one or more modules with a common theme, possibly organized into a module 
hierarchy based on a dependency relation. It contains declarations of sorts, attributes, and 
properties of the domain together with axioms describing them. Structures are used to de¬ 
scribe the domain’s objects. These features, together with the means for defining classes 
of a domain as special cases of previously defined ones, facilitate the stepwise develop¬ 
ment, testing, and readability of a knowledge base, as well as the creation of knowledge 
representation libraries. 


KEYWORDS', logic programming, reasoning about actions and change, action language 


1 Introduction 


In this paper we introduce a new modular action language, ACM, and illustrate 
the principles of its use. Our work builds upon the methodology for representing 
knowledge about discrete dynamic systems introduced by Gelfond and Lifschitz 


(1993 19981. In this approach, a system is viewed as a transition diagram whose 


nodes correspond to possible states of the system and whose arcs are labeled by ac¬ 
tions. The diagram is defined by a system description - a collection of statements in 
a high-level action language expressing the direct and indirect effects of actions as 


well as their executability conditions (see, for instance, action languages A (Gelfond 
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and Lifschitz 199 

3), B (Gelfond and Lifschitz 1998 

; AC (Turner 1997 Baral and 

Gelfond 2000); the non-modular extension of AC with multi-valued fluents (Dovier 

et al. 2007); C (C 

liunchiglia and Lifschitz 1998); C-|- (Giunchiglia et al. 2004); K. 

(Eiter et al. 200'! 

1; D (Strass and Thielscher 2012 

); £ (Kakas and Miller 1997); 

Tf (Chintabathina et al. 2005| Chintabathina 2012)). Such languages allow concise 


representations of very large diagrams. In order to reason about the system, its ac- 


tion language description is often translated into a logic program under the answer 

set semantics ( 

Gelfond and Lifschitz 1988 1991). This allows for the use of Answer 

Set Programming (ASP) (Gelfond and Lifschitz 1991 

Niemela 1998 

Marek and 


sis, etc. This methodology was successfully used in a number of interesting medium 
size applications, but does not seem to be fully adequate for applications requiring a 
larger body of knowledge about actions and their effects, step-wise design, and mul¬ 
tiple use of, possibly previously designed, pieces of knowledge. (The phenomenon is 
of course well known in Computer Science. Similar considerations led to the early 
development of notions of subroutine and module in procedural programming. In 
logic programming, early solutions were based on the concepts of macro and tem¬ 


plate (Baral et al. 2006 Calimeri and lanni 20061.) Just a few examples of domains 


that we consider large enough to benefit from the above-mentioned practices are: 


the Zoo World and Traffic World examples proposed by Erik Sandewall (Sande- 


the Monkey and Banana Problem by John McCarthy (McCarthy 1963 McCarthy 


1968) and formalized in (Erdogan and Lifschitz 2006 Erdogan 2008); the Mission¬ 


aries and Cannibals Problem by John McCarthy (McCarthy 1998) represented in 


wall 1999) and modeled in (]Henschel and Thielscher 1999 Akman et al. 2004) 


(Gustafsson and Kvarnstrdm 2004 Erdogan 2008). 


This inadequacy is due to the fact that most action languages, with some notable 
exceptions like MAD (Lifschitz and Ren 2006| Erdogan and Lifschitz 2006 Desai 


and Singh 2007) and TAL-C (Gustafsson and Kvarnstrdm 2004), have no built-in 


features for supporting the description of a domain’s ontology and its objects, and 
for structuring knowledge and creating knowledge-based libraries. A£M is designed 
to address these problems. It is based on an earlier action language, AC, introduced 


in (Gelfond and Inclezan 2009) where it is called ACd, which so far has been the 


authors’ language of choice (see, for instance, (Gelfond and Kahl 2014)). However 


the basic ideas presented in the paper can be used for defining versions of ACM. 
based on other action languages. 

ACM has constructs for representing sorts (i.e., classes, kinds, types, categories) 
of objects relevant to a given domain, their attributesQand a subsort relation that 
can be viewed as a directed acyclic graph (DAG). We refer to this relation as a sort 
hierarchy. These constructs support a methodology of knowledge representation 
that starts with determining the sorts of objects in a domain and formulating the 
domain’s causal laws and other axioms in terms of these sorts. The specialization 
construct of the language, which corresponds to the links of the sort hierarchy, 


^ Attributes are intrinsic properties of a sort of objects. In A£Ai they are represented by possibly 
partial functions defined on elements of that sort. 
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allows to define new sorts (including various sorts of actions) in terms of other, 
previously defined sorts. 

The definition of particular objects populating the sorts is usually given only 
when the domain knowledge is used to solve a particular task, e.g., predicting the 
effects of some particular sequences of actions, planning, diagnosis, etc. 

It is worth noting that allowing definitions of actions as special cases of other, 
previously defined actions was one of the main goals of actions languages like ACM 
and MAD. Such definitions are not allowed in traditional action languages. ACMA 
solution consists in allowing action sorts, which do not exist in MAD. We believe 
that the ACM solution is simpler than the one in MAD, where special cases of 
actions are described using import statements (similar to bridge rules in C+). 

ACM also facilitates the introduction of particular domain objects (including 
particular actions) that are defined as instances of the corresponding sorts. For 
example, an action go{bob, london, paris) can be defined as an instance of action 
sort move with attributes actor, origin, and destination set to bob, london, and 
paris respectively; action go{bob, paris) is another instance of the same sort in 
which the origin of the move is absent. Note that, since axioms of the domain are 
formulated in terms of sorts and their attributes, they are applicable to both of these 
actions. This is very different from the traditional action language representation 
of objects as terms, which requires separate axioms for go{bob, london, paris) and 
go{bob, paris). 

Structuring of knowledge in ACM is supported by the concepts of module, mod¬ 
ule hierarchy, and library, and by the division of a system description of ACM into 
two parts: theory and structure. Theories contain declarations of sorts, attributes, 
and properties of the domain together with axioms describing them, while struc¬ 
tures are used to describe the domain’s objects. Rather traditionally, ACM views 
a module as a formal description of a specific piece of knowledge packaged as a 
unit. A theory consists of one or more modules with a common theme, possibly 
organized into a module hierarchy based on a dependency relation. Modules of a 
theory can be developed and tested independently, which facilitates the reuse of 
knowledge and stepwise development and refinement (Wirth 1971) of knowledge 
bases, and increases their elaboration tolerance (McCarthy 1998). 

Theories describing recurrent knowledge may be stored in libraries and used in 
different applications. The structure part of an ACM system description contains 
definitions of objects of the domain together with their sorts, values of their at¬ 
tributes, and statics - relations between objects that cannot be changed by actions. 
If a system description of ACM satisfies some natural consistency requirements and 
provides complete information about the membership of its objects in the system’s 
sorts then it describes the unique transition diagram containing all possible trajec¬ 
tories of the system. In this sense ACM is semantically similar to AC. There are 
also some substantial differences. First, if no complete information about member¬ 
ship of objects in sorts is given, then the system description specifies the collection 
of transition diagrams corresponding to various possible placements of objects in 
the system’s sorts. This has no analog in AC. Second, in addition to the semantics 
of its system descriptions, ACM provides semantics for its theories. Informally, 
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a theory of ACM. can be viewed as a function taking as an input objects of the 
domain, their sort membership, and the values of static relations, and returning 
the corresponding transition diagram - a possible model of the theory. (This defi¬ 
nition has some similarity with the notions of module developed for logic programs 
under the answer set semantics, e.g. (Oikarinen and Janhunen 2006) and (Lierler 


and Truszczynski 2013). Accurate mathematical analysis of these similarities and 


their use for automatic reasoning in ACM is a matter for future research.) The 
availability of a formal semantics clarifies the notion of an ACM theory and allows 
us to define an entailment relation (T entails g if g is true in every model of T). 

To accurately define the semantics of ACM theories, we introduce the notion of a 
basic action theory {BAT) — a pair consisting of a specific type of sorted signature 
(which we call an action signature), and a set of axioms over this signature. An 
interpretation / of the signature of a BAT theory T defines: objects, their sort 
membership, and statics; while T can be viewed as a function that takes / as input 
and returns the transition diagram T{I) defined by I. In a sense, T{I) is very 
similar to system descriptions of AC and other traditional action languages. The 
difference is in the forms of their signatures and axioms. As in AC, the precise 
definition of states and transitions of T{1) is given in terms of its translation into 
logic programs under the answer set semantics. 

A system description D of ACM can be viewed as a formal definition of a par¬ 
ticular BAT theory T, and a class of its interpretations. The latter is given by 
the structure of D, the former by its theory. If the structure of D is complete, i.e., 
defines exactly one interpretation I, then D represents T{I). 

An earlier version of ACM has been tested in the context of a real-life application, 
as part of our collaboration on Project Halo. Project Halo is a research effort by 
Vulcan Inc. aimed towards the development of a Digital Aristotle - “an application 
containing large volumes of scientific knowledge and capable of applying sophisti¬ 
cated problem-solving methods to answer novel questions” (Gunning et al. 2010). 
The Digital Aristotle uses the knowledge representation language called SILK (Se¬ 
mantic Inferencing on Large Knowledge) (Grosof et al. 2009), which is based on 
the well-founded semantics (Van Gelder et al. 1991) and transaction logic with de¬ 
faults and argumentation theories (Fodor and Kifer 2011). Our first contribution 
to Project Halo consisted in creating an ACM formalization of an important bio¬ 
logical process, cell division (Inclezan and Gelfond 2011). The use of ACM allowed 
us to create libraries of knowledge and reuse information when representing the 
cell division domain. As a second step, we created a question answering system 
capable of answering complex temporal projection questions about this biological 
process (Inclezan 2010). Our model of cell division represented in the higher level 
language ACM served as a front end for the question answering system, which was 
implemented both in ASP and in the language of the Digital Aristotle. 

Our language has evolved since our collaboration on Project Halo. The version of 


ACM presented here differs from that described in previous papers (Gelfond and 


Inclezan 2009 Inclezan and Gelfond 2011) in various ways. We simplified and gen¬ 


eralized the basic concepts of our language, as well as its syntax and semantics. (We 
say more about the new features of ACM in the conclusion section of the paper.) 
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The reasoning in ACM is based on the reduction of temporal projection, planning, 
diagnosis, etc. to the problem of computing the answer sets of logic programs (for 


a general description see, for instance, (Baral 2003)) by ASP solvers (see (Niemela 


and Simons 1997), (Gebser et al. 2012), or (Leone et al. 2006)). 


The rest of this paper is organized as follows: we first introduce the concept of 
basic action theory, which is a fundamental concept in this work. We then describe 
language ACM and the methodology of ACM’s use. We end with conclusions 
and future work. There are three appendices containing the grammar of ACM 
(Appendix A), the description of the use of ACM in Digital Aristotle (Appendix B), 
and a comparison between ACM and MAD (Appendix C). 


2 Basic Action Theories 

In this section we give the definition of a fundamental concept of ACM called basic 
action theory {BAT). A BAT consists of a collection of axioms over a so called 
action signature — a special type of sorted signature providing suitable vocabulary 
for representing knowledge about dynamic domains. Sorted signatures needed for 
our purpose are somewhat atypical. They allow partial functions and contain means 
for describing a hierarchy of sorts and attributes of their elements. We start with 
the precise definition of sorted signatures and their interpretations. 


2.1 Sorted Signatures and Their Interpretations 

By sorted signature we mean a tuple 

E = {c,o,n,T) 

where C, O, and T are sets of strings over some fixed alphabet. The strings are used 
to name sorts, objects, and (possibly partial) functions respectively. Each function 
symbol f G T is assigned a positive integer n (called /’s arity), sorts cq, ..., c„ for 
its parameters, and sort c for its values. We refer to c as the range of / and use the 
standard mathematical notation f : cq x ... x Cn c for this assignment. 

Finally, "H is a sort hierarchy — a directed acyclic graph with two types of nodes: 
sort nodes labeled by sort names from C, and object nodes labeled by object names 
from O. Whenever convenient we identify nodes of the hierarchy with their labels. 
A link from sort ci to sort C 2 , denoted by (ci, C 2 ), indicates that elements of sort 
Cl are also elements of sort C 2 . We refer to C 2 as a parent of ci. A link from object 
o to a sort c, denoted by ( 0 , c), indicates that object o is of sort c. For simplicity, 
we assume that the graph has exactly one sink node, which corresponds to the sort 
containing all the elements of the hierarchy. A triple {0,0,11) will be sometimes 
referred to as an ontology. 

Sorts, object constants, and functions of a sorted signature are normally parti¬ 
tioned into user-defined, pre-deSned, and special. 

The collection of pre-dehned symbols may include names for some commonly 
used sorts and functions, such as: sorts booleans and integers] a sort [m..n] for 
every pair of natural numbers m and n such that m < n, denoting the set of 
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natural numbers in the closed interval [m, n]; standard object constants true, false, 
0, 1, 2, etc., denoting elements of these sorts; standard arithmetic functions and 
relations +, —, *, /, mod, <, <, etc. (The list is not exhaustive. When needed we 
may introduce other similar symbols.) All these symbols are pre-interpreted, i.e., 
come with their usual mathematical interpretations. 

The collection of special symbols consists of: 

• sorts and function symbols pertinent to sort hierarchies of sorted signatures: 

— Sort nodes denoting the collection of sorts labeling the sort nodes of H. 
This sort is never used as a label of a node in H. 

— Sort object-Constants denoting the collection of constants labeling the 
object nodes of H. This sort is never used as a label of a node in H. 

— Sort universe denoting the collection of elements of sorts from ji. 

— Function symbol link : nodes x nodes —> hooleans where link{ci, C 2 ) 
returns true iff Tf contains a link from sort ci to sort 02 - 

— Function symbol zs_a : universe x nodes —)■ booleans where is-a(x, c) 
returns true if c is a source node of H (i.e., c has no subsorts in H) and 
object X from the universe is of the sort denoted by c. 

— Function symbol instance : universe x nodes —)■ booleans denoting the 
membership relation between objects of the universe and the sorts of 
the domain. This function will be later defined in terms of function zs_a. 

— Function symbols subsort : nodes x nodes —)■ booleans, 
has-child, has-parent, sink, source : nodes —)■ booleans 
describing properties of sorts of "H and their members. All these func¬ 
tions (with their self-explanatory meaning) will be later defined in terms 
of function link. 

• Function symbol domf : Cq x ... x c„ —>■ booleans (read as domain of f) for 
every user-defined function symbol / : Cq x ... x c„ —>■ c with n > 0. 


Terms of a sorted signature are defined as usual: 

• A variable and an object constant is a term. 

• If / : Cq X ... X Cn —> c is a function symbol and to,... ,tn are terms then 
f{to,... ,tn) is a term. 

Expressions of the form 

ti = t 2 and ti ^ t 2 (1) 

are called literals. Positive literals are also referred to as atoms. (For simplicity of 
presentation we use standard shorthands and write t and ^t instead of t = true 
and t = false, respectively; 3 < 5 instead of < (3,5); etc.) Terms and literals not 
containing variables are called ground. Our notion of an interpretation of a sorted 
signature is slightly different from the traditional one. 
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Definition 1 (Interpretation) 

An interpretation X of S consists of 

• A non-empty set \I\ of strings called the universe of X. 

• An assignment that maps 

— every user-defined sort c oiH into a subset X(c) of |X| and user defined 
object constant o into an element from |X|; 

— every user-defined function symbol / : cq x ... x c„ —>■ c of S into a 
(possibly partial) function 1(f) : X(co) x ... x X(c„) —>■ X(c); 

— the special function is-a into function X(is-a) such that: 

— for every x G |X| and every sort c of H, I(is-a)(x, c) is true iff c is 
a source node of "H and x G 1(c) and 

— for every object o and sort c of H, X(is_a)(X(o), c) is true iff (o, c) G 

n; 

— the special function link into function X(link) such that for every two 
sort nodes ci, C 2 , X(link)(ci, C 2 ) is true iff (ci, C 2 ) G H; 

— the special function domf for user-defined function / : cq x ... x c„ —>■ c 
into function I(domf) such that for every x G X(co) x ... xX(c„), 
X(domf)(x) is true iff x belongs to the domain of X(/). 

• On pre-defined symbols, X is identified with the symbols’ standard interpre¬ 
tations. 

An interpretation X of S can be naturally extended to ground terms: if X is defined 
on terms ti,... ,tn and X(f ) is defined on the tuple (X(ti),... ,X(t„)) then 

X(f(L,tj) =aef I(f)(I(ti), ... ,X(t„))- 

Otherwise X(f(ti,... ,tn)) is undefined. 

Finally, we say that an atom ti = <2 is 

• true in X if both X(ti) and X(t 2 ) are defined and have the same value; 

• false in X if both X(ti) and X(t 2 ) are defined and have different values; and 

• undefined in X otherwise. 

Similarly, a literal ti 7 ^ t 2 is true in X if = t 2 is false in X; it is false in X if = t 2 
is true in X; and undefined otherwise. 

Note that every interpretation X can be uniquely represented by the collection of 
atoms that are true in this interpretation. For instance, for every sort c of H, X(c) 
can be represented as the set {instance(o, c) : X(o) G X(c)}; for a unary function /, 
X(f) can be viewed as the set {f(x) = y : X(x) G X(domf) and X(f)(X(x)) = X(y)}, 
etc. 


2.2 Action Signature and Axioms of a BAT 


Since ACM is a language for specifying properties of actions, in what follows we 
limit ourselves to action signatures — sorted signatures that 
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• contain a special sort actions and 

• have their user-defined and special function symbols divided into three dis¬ 
joint categories: attributes, statics, and fluents. Attributes describe intrinsic 
properties of objects of a given sort; statics and fluents describe relations be¬ 
tween objects. Values of attributes and statics are constants - they cannot 
be changed by actions. The values of fluents can. Both statics and fluents are 
further divided into basic and defined. The latter are total boolean functions 
that can be defined in terms of the former. They are used primarily for the 
brevity of representation. 


A literal (atom) in which / is an attribute is called an attribute literal (atom). 
Similarly for static and fluent literals that are, in turn, divided into basic and 
defined. We assume that all special functions of an action signature, except doruf, 
are defined statics; damj is a basic fluent when / is a basic fluent and a defined 
static otherwise. Since the semantics of ACMi will be defined in terms of a version 
of ASP with function symbols, ASPjf} (Balduccini 2013), which does not allow 
terms with nested user-defined functions, we limit atoms of an action signature to 
those constructed from terms with at most one user-defined function symbol. (This 
is not a serious limitation and can easily be avoided by viewing nested terms as 
shorthands.) 

We can now define the syntax and informal semantics of statements of a BAT over 
a fixed action signature S. Variables in these statements are universally quantified. 


Definition 2 (Statements of a BAT) 

• A dynamic causal law is an expression of the form 


occurs(a) causes f{x) = o if instance(a, c), cond 


( 2 ) 


where a and o are variables or object constants, / is a basic fluent, c is the 
sort actions or a subsort of it, and cond is a collection of literals. The law says 
that an occurrence of an action a of the sort c in a state satisfying property 
cond causes the value of f(x) to become o in any resulting state. 

• A state constraint is an expression of the form 


f(x) = o if cond 


( 3 ) 


where o is a variable or an object constant, / is any function except a defined 
function, and cond is a collection of literals. The law says that the value of 
f(x) in any state satisfying condition cond must be o. Additionally, f(x) = o 
can also be replaced by the object constant false, in which case the law says 
that there is no state satisfying condition cond. 

• The definition of a defined function p is an expression of the form 

p(ti) if condi 

..._ (4) 

pitk) if condk 

where ts are sequences of terms, and condi,..., condk are collections of lit¬ 
erals. Moreover, if p is a static then condi,..., condk can not contain fluent 
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literals. Statements of the definition will be often referred to as its clauses. 
The statement says that, for every Y, p{Y) is true in a state a iff there is 
1 < m < k such that statements condm and I™ = Y are true in a. 

• An executability condition for actions is an expression of the form 

impossible occurs{a) if instance{a, c), cond (5) 

where a is a variable or an object constant, c is the sort actions or a subsort 
of it, and cond is a collection of literals and expressions of the form occurs{t) 
or —>occurs{t) where t is a variable or an object constant of the sort actions. 
The law says that an occurrence of an action a of the sort c is impossible 
when condition cond holds. 

Dynamic causal laws and constraints will be sometimes referred to as causal laws. 
We use the term head to refer to Hn ([^ and ([^, and to any of the p(ti), 1 < i < k, 
in Q. We call body the expression to the right of the keyword if in statements 
(§, or in any of the statements of Q . Statements not containing variables 
will be referred to as ground. 

Definition 3 {Basic Action Theory - BAD) 

A Basic Action Theory {BAD) is a pair consisting of an action signature S and a 
collection T of statements over S (called axioms of the theory) such that: 

• If / is a basic fluent then 

— T contains a state constraint: 

domf{Xo,...,Xn)i{f{Xo,...,Xn)= Y (6) 

— No dynamic causal law of T contains an atom formed by domf in the 
head. 

• If / is a defined fluent, a static, or an attribute then T contains the definition: 

dom/(Ao,...,A„)if/(Ao,...,X„)= F (7) 

• T contains definitions of special statics of the hierarchy given in terms of 
functions ism and link: 


instance{ 0 , C) 

if 

ism{ 0 , C) 

instance{ 0 , C2) 

if 

instance{ 0 , Ci), link{Ci, C2) 

hasmhild{C 2 ) 

if 

link {Cl, C2) 

has-parent{Ci) 

if 

link {Cl, C2) 

source{C) 

if 

-^has-child{C) 

sink{C) 

if 

-^has-parent{C) 

subsort{Ci, C2) 

if 

link{Ci, C2) 

subsort{Ci, C2) 

if 

link{Ci, C), subsort{C, C2) 


To simplify the notation, in what follows we will often identify a theory with the 
collection of its axioms. Axioms (§-§ above are self-explanatory, with the possible 
exception of the restriction prohibiting the appearance of doruf in the head of 
dynamic causal laws. To understand the latter requirement it is sufficient to notice 
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that it is not enough to include object O in the domain of basic fluent / — it is also 
necessary to specify the value of f{0). Otherwise the causal law making domf{0) 
true would become non-deterministicj^ which is not allowed in the current version 
of ACM.. The presence of a law assigning a value to f{0) makes dynamic causal 
laws with domf in the head unnecessary. It is however useful to allow dynamic 
causal laws with ^domf{0) in the head as a simple way of removing O from the 
domain of /. 

The following is an example of a basic action theory. 

Example 1 {A Basic Action Theory T^) 

Let us consider an action signature with three sorts, ci, C 2 and C 3 , the special 
sorts universe and actions, and the pre-defined sort booleans, organized in a hierar¬ 
chy TL^ in which universe is the parent of ci, ci is the parent of C2, C3, actions, and 
booleans, and object constant o is of sort C3; attributes attri, attr 2 : actions —>■ C3; 



Fig. 1. Hierarchy of 


basic fluents f, g ■ C 2 ^ c^; and special functions like link, is-a, domf, domg. The 
hierarchy TL^ can be seen in Figure [l] but we omitted from the picture the sort 
universe whose only child is Ci. 

The basic action theory T® over consists of the causal laws 


occurs{A) causes j{X) = F if 

occurs (A) causes ^domf{X) if 

false if ^domg{X), 

instance(X, C 2 ). 


instance{A, actions), 
attri{A) = Y, 
g{X) = o 

instance{A, actions), 
attr 2 {A) = o 


The third axiom requires function g to be total. 


In addition, contains standard BAT axioms: 


^ To see why, consider, for instance, a basic fluent / declared as f : {0,1} —t {0,1} and a dynamic 
causal law ^Pccurs{a) causes domf(l).” Intuitively, the axiom says that after a is executed 
/(I) must be defined, i.e., /(I) = 0 or /(I) = 1, which is non-deterministic. 
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State constraints for the basic fluents: 
domf{X) if f{X) = Y 
domg{X) if g{X) = Y 

Definitions for the domains of attributes: 

doniattriiX) if attri{X) = Y 
domattr2{X) if attr2{X) = Y 

and the collection of axioms from (8). 


2.3 Semantics of BATs 

Intuitively, a basic action theory T defines the collection of discrete dynamic sys¬ 
tems satisfying its axioms. The semantics of T will describe such systems by specify¬ 
ing their transition diagrams, often referred to as models of T. Nodes of a transition 
diagram represent possible states of the dynamic system; arcs of the diagram are 
labeled by actions. A transition (tJo, o-,ai) says that the execution of action a in 
state (To may take the system to state cri. 

A state of the diagram will be defined by the universe — a collection of objects 
of the sorts of T, and by a physically possible assignment of values to T’s func¬ 
tions. Moreover, we assume that the sorted universe and the values of statics and 
attributes are the same in all states, i.e., states only differ by the values of fluents. 

To make this precise it is convenient to partition an interpretation I of an action 
signature S into two parts: fluent part consisting of the universe of I and the 
restriction of X on the sets of fluents, and static part consisting of the same universe 
and the restriction of I on the remaining elements of the signature. Sometimes we 
will refer to the latter as a static interpretation of E. 

We also need the following notation: Given an action signature S and a collection 
U of strings in some fixed alphabet, we denote by Ey the signature obtained from 
E by expanding its set of object constants by elements of U, which we assume to 
be of sort universe. 

Definition 4 {Pre-model) 

Let T be a basic action theory with signature E and U he a collection of strings in 
some hxed alphabet. A static interpretation M of Ey is called a pre-model of T 
(with the universe U) if M{universe) = U and for every object constant o of Ey 
that is not an object constant of E, M{o) = o. 

Given a pre-model M with the universe U we will often denote signature E[/ by 

Cm- 

To illustrate this notion let us consider a pre-model of theory T from Example 

m 

Example 2 {A pre-model of Basic Action Theory T^) 

To define a pre-model of basic action theory from Example let us consider 
a static interpretation M with the universe Um = {x,y, z, aA,P'u-e, false} such 
that: 
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M{umverse) = M.{ci) = {x, y, z, a, b, true, false}; 

M(c 2 ) = { 2 ;}; 

M(c 3 ) = {y,z}, 

M{actions) = {a, b}; 

■M{o) = {y}; and 
M{attri){a) = M.{attr 2 ){b) = y. 

In addition: every symbol from Uj,^ is added to S ^ and mapped into itself; doniattri = 
{a}, domattr 2 = {^}j the interpretation of special function link is determined by 
the hierarchy from Figure the interpretation of is-a is extracted from the inter¬ 
pretation of the hierarchy’s sorts. 

Clearly, M. satisfies the conditions in Definition and hence is a pre-model of T°. 


A pre-model M of T uniquely defines a model Tm of T if such a model exists. 
The definition of Tm will be given in two steps: first we define T>i’s states and 
then its transitions. 


Intuitively, if theory T does not contain definitions, then a state of Tj^ is an 
interpretation I with static part Mi that satisfies the state constraints of T. The 
situation is less simple for theories containing definitions (especially recursive ones). 
Similar to the case of AC, the definition of a state will be given using logic programs 
under the answer set semantics; specifically, we will use logic programs with non- 
Herbrand partial functions in the language ASP{f} ( Balduccini 2013[ )p] 

Let be a pre-model of action theory T. 


Program Sm'- 

By Sm we denote a logic program that consists of: 


a) rules obtained from the state constraints and definitions of T by replacing 
variables with properly typed object constants of Cm, replacing object con¬ 
stants with their corresponding interpretations in Mi, removing the constant 
false from the head of state constraints, and replacing the keyword if with 

b) the Closed World Assumption: 

^d{h), -It- not d{to, 

for every defined function d \ Cq x ... x Cn ^ booleans and f G Af(ci), 
0 < i < n. 


end of Sm- 

Finally, we define a program Sx used in the definition of states of the transition 
diagram defined by Ai. 

Program Sx- 


® Other approaches for introducing non-Herbrand functions in ASP can be seen, for instance, in 
([Cabalar 2011|[Lifschitz 2012[[Bartholomew and Lee 2013[|. 
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For every interpretation I of S with static part M, by Si we denote the logic 
program obtained by adding to Sm the set of atoms obtained from I by removing 
the defined atoms, 
end of Si 
Definition 5 (State) 

Let be a pre-model of a BAT theory T. An interpretation a with static part 
TW is a state of the transition diagram Tm defined by Al if cr is the only answer 
set of Sa- 

Notice that a is not a state if Sa has multiple answer sets, a situation that would 
only occur when the value of some defined function is not completely determined 
by the values of basic functions. We will return to this issue later, in Section 

Example 3 (States of the diagram) 

Let M be the pre-model of theory T® from Example [ 2 ] The program Sm for this 
M looks as follows: 

^ ^domg(x), instance(x, C 2 ) 

domf(x) ^ f(x) = y 
domf(x) ^ f(x) = z 
domg(x) ^ g(x) = y 
domg(x) ^ g(x) = z 

domattri(a) attri(a) = y 
domattri(a) ^ attri(a) = z 
domattr 2 (a) ^ attr 2 (a) = y 
domattr 2 (o) ^ attr 2 (a) = z 
domattri(b) ^ attri(b) = y 
domattri(b) ^ attri(b) = z 
domattr 2 (b) ^ attr 2 (b) = y 
domattr 2 (b) ^ attr 2 (b) = z 

and the Closed World Assumptions for the special functions. Recall that, accord¬ 
ing to the definition of an interpretation of a sorted signature, for every x G |I|, 
I(is-a)(x, c) is true iff c is a source node of the sort hierarchy and D(x) G T(c), 
and for every object o and sort c, L(is-a)(L(o), c) is true iff (o, c) is a link in our 
hierarchy. This, together with the condition on the interpretation of link guaran¬ 
tees that every state of Tm contains atoms is-a(x, C 2 ), is-a(y, C 3 ), and other atoms 
formed by is^a and link that define our hierarchy. The collection of these atoms 
together with the closed world assumptions for is_a, link and the other defined 
statics uniquely determine their values. It is easy to check that every state of M 
contains literals formed by these special fluents. Every state of Tm also contains 
attri(a) = y, attr 2 (b) = y, and domg(x). Overall, Tm has the following six states 
(for each state, we only show non-special fluents): 

0-1 = {fix) = y, 9(x) = y} 0-2 = {f(x) = z, g(x) = y} 

<X 3 = {f(x) = y, g(x) = z} 0-4 = {f(x) = z, g(x) = z} 

0-5 = {9(x) = y} 0-6 = {g(x) = z}- 
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In addition, states cri,cr 2 ,cr 3 , and <7a contain domf{x) while states (J 5 and ae, in 
which / is undefined on x, contain ^domf{x). 

To define transitions of the diagram that corresponds to a pre-model A4 with the 
universe U, we construct a logic program Pm whose signature is obtained from the 
signature of program Sm defined above by 

• adding a new sort, step, ranging over 0 and 1 ; 

• replacing every fluent / : Cq x ... x c„ —>■ c by function 
/ : Cq X ... X c„ X step —)■ c; 

• adding a function symbol occurs : actions x step —>■ booleans. 

Program Pm ■ 

Program Pm is obtained from a theory T and pre-model Ai by 

a) replacing variables by properly typed object constants of ^m'j 

b) replacing object constants by their corresponding interpretations in A4; 

c) removing the object constant false from the head of state constraints; 

d) replacing every occurrence of a fluent term f(t) in the head of a dynamic 
causal law by f(i, I + 1); 

e) replacing every other occurrence of a fluent term f(t) hy fit, I); 

f) removing occurs{a) causes” from every dynamic causal law and adding 
occurs (a) to the body; 

g) replacing “impossible occurs(o)” in every executability condition by ^occMrs(a); 

h) replacing occurs (a) by occurs (a, I) and -^occurs (a) by -^occurs {a, I); 

i) replacing the keyword if by •<—; 

j) adding the Closed World Assumption: 

, tn, d) i not ■ 5 tfi, /) 

for every defined fluent d : cqX .. .x Cn booleans and U € AAici), 0 < i < n; 

k) adding the rule: 

^/(to,..., t„) ^ not /(to, ■■■,tn) 

for every defined static of the form / : cq x ... x c„ —>■ booleans and / € A4 (ci), 

0 < i < n; 

l) adding the Inertia Axiom: 

domfit{),...,tn,I +1) ^ donifito,... ,tn,I), 

not ^domfito ,..., t„, d -I- 1 ) 
-^domf{to,...,tn,I + l) ^ ^domfito,...,t„,I), 

not domfito ,..., t„, / -|- 1 ) 

for every basic fluent doruf : Cq x ... x c„ —>■ booleans, and ti G A4(ci), 

0 < i < n; 

m) adding the Inertia Axiom: 

f{to,...,tn,I+l) = t G- donif{to,...,tn,I+l), 

fih,...,tn,I) = t, 

not /(to, ■ ■ ■ ,tn,I + 1) ^ t 
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for every basic fluent / : cq x ... x c„ —>■ c not formed by dom, and U G M{ci), 
0 < i < n, and t G M{c). 

end of Pm 


Note that the last axiom is a modification of the standard logic programming version 
of the Inertia Axiom (see, for instance, (Gelfond and Kahl 20141), which is stated 
for total (boolean) functions. The main difference is the addition of the domain 
statements in the body. The inertia axiom for the function domf is of the standard 
form. 


Program P{M, ag, a): Let (Tq be a state of the transition diagram defined by a pre¬ 
model M, and let a C M[actions). By P{M,ao, a) we denote the logic program 
formed by adding to Pm the set of atoms obtained from (Tq by replacing every 
fluent atom ... ,tn) = t hy f (to,... ,tn,0) = t and adding the set of atoms 
{occiirs(a;, 0) : x G a}, 
end of P{M,ao, a) 

Definition 6 ( Transition) 

Let (To and ai be states of the transition diagram defined by a pre-model M and 
let a C M{actions). The triple (ctq, a,ai) is a transition of the transition diagram 
defined by a pre-model M of a BAT theory T if program P{M,ao, a) has an 
answer set A such that f{to,... ,tn) = t G cti iff 

• / is an attribute or a static and /(to, ... ,tn) = t G A, or 

• / is a fluent and /(to, ... , f„, 1) = < G A. 


Definition 7 (Model) 

A transition diagram Tm defined by a pre-model Al of a basic action theory T is 
called a model of T if it has a non-empty collection of states. 

The following example illustrates the definition. 

Example 4 (A Model of Basic Action Theory T^) 

To define a model of theory from Example let us consider the pre-model M 
from Example States of the diagram defined by this pre-model were given in 
Example To define the transitions of the model defined by M we use Definition 
1^ Let us illustrate this by showing that a triple (oi, b,a^) is a transition. To do 
that we need first to construct a program P(M, cri,b) (we are only showing rules 
relevant to our argument): 

[1] f(x, 1) = y G- instance(b, actions), 

occurs(b, 0), 
attri(b) = y, 
g(x,0) = y. 

[2] -^domf(x,l) G- instance(b, actions), 

occurs(b, 0), 
attr 2 (b) = y. 
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[3] domf{x,0) ^ f{x,0) = y. 
donifix, 1 ) ^ f{x, 1 ) = y. 
domg{x,0) ^ g{x,0) = y. 
dorugix, 1) ^ g{x, 1) = y. 

[4] f{x,l) = y ^ domf{x,l), 

f{x,0) = y, 
not f{x, 1 ) ^ y. 

g{x,l) = y ^ domg{x,l), 
gix,0) = y, 
not g{x, 1 ) ^ y. 

[5] domf{x,l) ^ domf{x,0), 

not ^domf{x, 1 ). 

domg{x,l) ^ domg{x,0), 

not ^domg{x, 1 ). 

[ 6 ] f{x,0) = y. 
g{x,0) = y. 
occurs{b, 0 ). 

It is easy to see that the program has a unique answer set, say, S. Since cts = 
{g{x) = y} we need to show that the only fluent atom with the step parameter 1 
belonging to S is g{x, 1) = y. By the second rule from group [5], domg{x, 1) € S. 
By the second rule of [4] we have that g{x, 1) = y G S. As expected, function g 
maintains its value by inertia. The situation is different for /. By rule [2] we have 
that ^domf{x, 1) G 5 and hence neither rule [5] nor [4] for / are applicable. Rule [1] 
is also not applicable since attri is not defined for b. Therefore the state defined by 
S is exactly cts = {g{x) = y}. (Note that the argument would not be possible if we 
were to use the traditional version of the Inertia Axiom. The modification related 
to the treatment of dom presented in axioms [4] and [5] is essential.) 

Using the same method one can easily verify that triples {a 2 ,a,ai), ((J 5 ,a,fTi), 
(ct 5 , b,a^), etc. are transitions of the transition diagram defined by A4. 

2-4 Entailment Relation 

Let us consider a fixed action theory T with action signature S, and define an 
entailment relation between T and statements of S. 

Let I be an interpretation of S. A ground instance of a statement a of E with 
respect to X is a statement obtained by replacing variables of a by properly typed 
object constants in Ex and replacing object constants of a by their interpretations 
in X. 

Now let us consider a model Tj^ of a basic action theory T defined by a pre-model 
A4 with the universe U and let cr be a state of Xa^ . 
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Definition 8 {Satisfiability Relation for Ground Statements of a BAT) 

• A state cr of T^i satisfies a ground state constraint a if cr contains the head 
of a whenever it contains its body. 

• A state cr of Ta 4 satisfies a ground definition a if cr contains the head of a 
clause in a iff q; contains a clause with the same head and the body belonging 
to cr. 

• A transition (erg, a,cri) of Tjn satisfies a ground dynamic causal law a that 
starts with the expression “occurs{e) causes” if a contains action e and cti 
contains the head of a whenever erg contains its body. 

• A transition (ctq, a, ai) of satisfies a ground executability condition a that 
starts with the expression “impossible e” if either ( 1 ) a does not contain e 
or ( 2 ) the body of a contains: 

— a ground literal I such that Z ^ erg, or 

— an expression “occMrs(ei)” such that ei ^ a, or 

— an expression “—'Occurs{02)” such that 62 S a. 

Definition 9 {Satisfiability Relation for Arbitrary Statements of a BAT) 

Let Tj^ be a model of a basic action theory T defined by a pre-model M with the 
universe U. 

• satisfies a constraint a over signature E of T if every state of T _\4 satisfies 
all ground instances of a with respect to U. Similarly for definitions. 

• satisfies a dynamic causal law a over signature E of T if every transition 
of Ta 4 satisfies all ground instances of a with respect to D. Similarly for 
executability conditions. 


Definition 10 {Entailment) 

A statement a is entailed by a theory T (T |= cr) if a is true in every model of T. 

Having the notion of entailment allows us to investigate the relationship between 
causal laws. For instance we can show that 

{occurs{A) causes / if p, q; occurs{A) causes / if ^p} \= occurs{A) causes / if g 


{occurs{A) causes / if p, g; g if p} |= occurs{A) causes / if p 
etc. Our notion of entailment is somewhat similar to the notion of subsumption 
from ( |Eiter et al. 2010 ) - a relation between an action description and a query 
(including queries having the form of causal laws and executability conditions). 
Our entailment relation can be viewed as a generalization of subsumption from 
system descriptions to theories. It allows variables and, unlike that of subsumption, 
is defined in terms of multiple transition diagrams specified by the theory. There 
are also related formalisms that allow entailment of causal laws and executability 
conditions (see, for instance ( [Turner 1999 ) and (Giunchiglia et al. 2004)). There 
are many interesting problems related to the ACM entailment, including that of 
finding a sound and complete set of inference rules for it. We hope to address these 
problems in our future work. 
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3 Language ACMi 


In this section we use examples to introduce the syntax of theories and system 
descriptions of ACMi and define their semantics. (The full grammar for the language 
can be seen in Appendix A| ) 

We begin with describing unimodule system descriptions, i.e. system descriptions 
whose theories consist of exactly one module. 


3.J Unimodule System Descriptions 

We start with a comparatively simple problem of formalizing the domain described 
by the following story: 

Example 5 {A Travel Domain) 

Consider a travel domain in which there are two agents, Bob and John, and three 
locations. New York, Paris, and Rome. Bob and John can move from one location 
to another if the locations are connected. 


If we were to represent this knowledge in AC we would start with identifying ob¬ 
jects of the domain including actions such as, say, go{bob, paris, rome) and write 
AC axioms describing the relationships between these objects. The use of ACM 
suggests a very different methodology. 


Methodology of Describing Dynamic Domains in ACM'. 


1. Determine what sorts of objects are relevant to the domain of discourse and 
how these sorts can be organized into an inheritance hierarchy. 

2. Use ACM to describe the basic action theory for this type of domains. This 
should be done in two steps: 


• Describe the action signature of our abstraction by declaring sorts (to¬ 
gether with their attributes and the inheritance hierarchy), basic and 
defined statics and fluents. (Notice that this signature normally will not 
contain particular objects of our story. It would have no mention of 
Bob, Paris, etc. However, the signature may include some object con¬ 
stants pertinent to the general domain of the story - see for instance 
the Monkey and Banana Problem in Section 4.1 ) 

• Use this action signature to formulate axioms of the theory. 


3. Populate sorts of your hierarchy with objects relevant to your story and de¬ 
scribe these objects and their sort membership in ACM. 


As is the case with other problem solving methodologies, we begin by choosing a 
proper level of abstraction for our example. Since the example is used for illustrative 
purposes we opted for using the following simple abstraction: 

Our domains will contain things and discrete points in space. Certain things, 
called agents, will be able to move from one point to another if the two points are 
connected. We are interested in the relations between points and the locations of 
things, including changes of these locations caused by a sequence of given moves. 
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(Note that our abstraction does not allow a location to be a part of another location, 
e.g., we will not be able to express that Paris is located in France. It ignores the 
means of transportation, the possibility that locations may have restrictions on the 
number of things they can contain, etc.) 

Accordingly, our basic action theory containing commonsense knowledge about 
motion formulated in these terms will include sorts things, agents, points, and 
move, together with special sorts universe and actions, which belong to every action 
signature. 

We call this basic action theory Tj™. The sorts of will be organized in a 
hierarchy depicted in Figure 



Fig. 2. Sort Hierarchy for Tbm 


Our next step is to describe in ACM. 

Example 6 {Motion Theory in ACM) 

The description of a theory in ACM starts with the keyword theory and is followed 
by a collection of modules. Our theory, called basic-motion, consists of only one 
module moving 

theory basiC-motion 
module moving 
{module body) 

where {module body) stands for the declarations of sorts, functions, and axioms of 
the theory. We assume that things, points, and agents have no attributes, while 
actions from the sort move may come with attribute actor indicating the agent 
involved in the action, and attributes origin and destination (abbreviated as dest) 
describing the locations of the actor before and after the execution of the action. 
Syntactically, all this information is specified as: 

sort declarations 

points, things :: universe 
agents :: things 
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move :: actions 
attributes 

actor : agents 
origin : points 
dest : points 

The construct :: is called specialization and corresponds to the links of the sort 
hierarchy; for instance, the link from agents to things in Figure is recorded by 
the statement agents :: things. Multiple links going into the same sort can be 
recorded by a single statement, as in points, things :: universe. Note that the 
special sorts universe and actions do not have to be declared. In case of a sort 
hierarchy with multiple links from c to pci ,..., pck we will use a specialization 
statement of the form c :: pci ,..., pck. In describing the attributes of actions 
of the sort move we use a shorthand. Attributes of move are functions defined on 
elements of the sort move, which means that the definition of, say, attribute actor 
should be written as actor : move —^ agents. After some deliberation however, 
we decided to allow to write it simply as actor : agents. The same agreement 
holds for attributes with a larger number of parameters; an attribute of a sort 
c that has the form attr^name : c x cq x ... x Cn —>■ Cn+i can be written as 
attr.name : cq x ... x Cn —t Cn+i. This completes the description of the syntactic 
representation of our sort hierarchy in A£A4. 

The next step is to syntactically describe functions in the signature. One of the 
functions mentioned in our informal description specihes whether two points are 
connected or not. Let us call it connected. In general, the value of connected can 
be changed by actions (airports can be closed, roads blocked, etc.) and hence we 
define connected to be a basic fluent. In some scenarios, the property connected 
will be a symmetric relation but not in others; similarly, it may be a transitive 
relation or not. To allow for elaboration tolerance, we introduce two basic static 
functions, symmetric-connectivity and transitive-connectivity to characterize the 
property connected. The other function relevant to our domain maps things into 
points at which they are located. Let us call it loc-in. The value of the function can 
be changed by actions of our domain, hence it is a fluent. It is not defined in terms 
of other functions, thus it is a basic fluent. It is also a total function, as we assume 
that the location of every thing is defined in every state. In ACM. these functions 
are syntactically declared as: 

function declarations 
statics 
basic 

symmetric-Connectivity : booleans 
transitive-Connectivity : booleans 

fluents 

basic 

connected : points x points —)■ booleans 
total loc-in : things —>■ points 
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In this example the keywords function declarations are followed by the lists 
of statics and fluents. Elements from each list are divided into basic and defined 
with each total function in the list preceded by the keyword total. Naturally, the 
declaration of a sort, static, or fluent in a module should be unique. 

This concludes our description of action signature of 

Now we are ready to define the collection of axioms of In ACM, we precede 
this collection by the keyword axioms. Each axiom will be ended by a period (.), 
as in: 


axioms 

occurs{X) causes locAn{A) = D if instance(X, move), 


actor (X) = A, 
dest{X) = D. 


connected{X, X). 
connected{X, Y) 


if 


■^connected{X, Y) if 


connected{X, Z) 


if 


connected{Y, X), 
symmetric-Connectivity. 

—'Connected{Y, X), 
symmetric-Connectivity. 
connected{X, Y), 
connected(Y, Z), 
transitive-Connectivity. 

impossible occurs(X) if instance{X, move), 

actor[X) = A, 
loc-in{A) ^ origin{X). 

impossible occurs{X) if instance{X, move), 

actor[X) = A, 
loc-in(A) = dest(X). 

impossible occurs{X) if instance{X, move), 

actor[X) = A, 
loc-in{A) = O, 
dest{X) = D, 
connected{0, D). 

The keyword total in the declaration of the basic fluent loc-in stands for the axiom 

false if -^domioc_m{X). 

that would otherwise have to be included among the axioms above. In general, the 
keyword total included in the declaration of a function / : cq x ... x c„ —>■ c stands 
for the axiom 


false if ^domf{Xo,..., X„). 


^ The description does not mention object constants, which can be declared in XCXi by state¬ 
ments o : c and r(ci,... , c„) : c. The first statement defines object constant o of sort c; the 
second defines the collection of object constants of the form r(xi,..., Xn) where xi,..., are 
object constants from sorts ci,..., c„. Example of the latter can be found in module climbing 
of Monkey and Banana representation from section[4.1| 
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This completes our description of the basic action theory in ACM. 

Note that the semantics of the unimodule ACM theory hasic-motion is given by 
the basic action theory Tf,™ defined by it. In the following sections we will present 
other examples of basic action theories and their interpretations represented in 
ACM. (Whenever possible we will make no distinction between these theories and 
their ACM representations.) 

As discussed above, a basic action theory T is used to define the collection of its 
models — transition diagrams representing dynamic domains with shared ontology 
and properties. Usually, a knowledge engineer is interested in one such domain, 
characterized by particular objects, sorts, and values of statics. If the engineer’s 
knowledge about this domain is complete, the domain will be represented by a 
unique model of T. Otherwise there can be several alternative models. 

The syntactic construct of ACM used to define such knowledge is called a struc¬ 
ture and has the form 

structure name 
{structure body) 

where {structure body) stands for the definition of objects in the hierarchy of 
and the values of its statics. Let us illustrate the use of this construct by the 
following example: 

Example 7 {ACM ’s Representation of a Speeific Basic Motion Domain.) 

Let us consider the ACM theory basic-motion from Example which encodes 
the basic action theory Thm, and use ACM to specify the particular basic motion 
domain from Example 

The ACM definition of the structure used to describe this domain starts with 
the header: 

structure Bob_andMohn 
followed by the definition of agents and points: 

instances 

bobAohn in agents 
new_york, paris, rome in points 

To specify particular actions of our domain we expand our list of instances by 

go{X,Pi,P 2 ) in move where Pi 7 ^ P 2 
actor = X 
origin = Pi 
dest = P 2 

Note that the last definition describes several instances simultaneously via the use 
of variables; we call this type of definition an instance schema. The instance schema 
defining go{X, Pi, P 2 ) stands for the collection of instance definitions: 


Modular Action Language ACM 


23 


go{bob, new-york, paris) in move 
actor — bob 
origin = new-york 
dest = paris 

go{john,paris,rome) in move 
actor = john 
origin = paris 
dest = rome 

The condition where Pi ^ P 2 ensures that Bob and John do not move to a 
destination identical to the origin. 

The following would also be a valid instance schema: 
go{X,P) in move 
actor = X 
dest = P 

if we were interested only in the destinations of Bob and John’s movements, but 
not in their origins. 

In our example connectivity between points is both symmetric and transitive: This 
is captured syntactically by the following: 
values of statics 

symmetric-Connectivity. 
transitive-Connectivity. 

This concludes our definition of Bob-and-John structure. 

To syntactically relate a theory with its structure, we use the construct of ACM 
called system description. In our case it will look as follows: 

system description travel 
theory basic-motion 
module moving 
{module body) 
structure Bob-and-John 
{structure body) 

where {module body) and {structure body) are defined in Examples and The 
system description travel contains all the information we considered relevant to our 
particular travel domain. It is not difficult to see that this knowledge is complete and 
therefore describes exactly one model (i.e., one transition diagram) of basic-motion. 
This is exactly the model we intended for our domain. A part of this model can be 
seen in Figure We only show fluent loc-in and assume that in every state of the 

® If a theory contains an object constant o then its value, say y, can be declared as: 

object constants 

o = y 

If the structure contains no assignment of value to constant o, we assume that o belongs to the 
structure’s universe and is mapped into itself. 
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part of the diagram shown in the picture Paris and Rome are connected to each 
other, but neither of them is connected to New York; we use shorthands b, j, ny, 
p, and r for bob, john, new^york, paris, and rome respectively; and we only show 
arcs that are labeled by a single action. 


goO, m,p) 



Fig. 3. (Partial) Transition Diagram for System Description travel 

The model is unique because we specified the membership of our objects in the 
source nodes of the hierarchy. This information is sufficient to uniquely define the 
universe and the interpretations of all the sorts. 

The next example illustrates how incomplete information about a domain can 
lead to multiple models of the system description of this domain: 

Example 8 {System Description with Multiple Models) 

Consider a system description underspeciSed-hierarchy consisting of a theory pro¬ 
fessors and a structure alice: 
system_description underspecified ^hierarchy 
theory professors 
module professors 
sort declarations 
professor :: person 
assistant, associate, full :: professor 
axioms 

false if instance{X, Ci), instance{X, C 2 ), 

link ( Cl, professor), link ( C 2 , professor), 

Cl ^ C2- 
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structure alice 
instances 

alice in professor 

The theory describes a simple hierarchy. The structure populates the hierarchy 
with one member, Alice (see Figure [^. Unfortunately all we know about Alice is 
that she is a professor. It is not difficult to check that this system description has 
three models. In the first one Alice is an assistant professor, in the second she is an 
associate professor, and in the third one - a full professor. 



Fig. 4. Underspecified Hierarchy 

We hope that these examples gave the reader a sufficient insight in the meaning 
of unimodule ACM theories and system descriptions. In general, the semantics of 
a syntactically correct unimodule theory T of ACM is given by the unique BAT 
defined by T. Similarly, the semantics of a system description D of ACM is given 
by models of the BAT theory defined by T and by the set of interpretation defined 
by the structure of D. 


3.2 Organizing Knowledge into Modules 

So far we only considered very simple ACM theories consisting of one module. To 
create theories containing a larger body of knowledge we need multiple modules 
organized into a module hierarchy. To illustrate this concept let us consider an 
extension of basic action theory Tf,m of motion by an additional sort of things 
called carriables, which can be carried between connected points by agents that are 
holding them. Recall from Example that we represented the original Tm as an 
ACM theory called basic-motion, with a unique module moving. We will use the 
name motion for the ACM theory that will specify the extension of Ti,m- The new 
theory will contain the moving module developed above as well as a new module 
called carrying-things'. 
theory motion 
module moving 
{module body) 
module carrying-things 
{module body) 

In addition to sorts, fluents, and axioms from module moving, the signature of the 
new module carrying-things will contain two new sorts, carriables and carry, a 
new inertial fluent, holding', and a defined fluent, is-held. Informally, holding will 
be understood as having in one’s hands and carry as moving while holding, which 
will allow us to define carry as a special case of move. 
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The dependency of carrying-things on moving is expressed in ACM. by the syn¬ 
tactic construct depends on called module dependency as follows: 

module carrying-things 
depends on moving 

This says that the sorts and functions explicitly declared in carrying-things depend 
on sorts and functions declared in the module moving. We say that the declarations 
of moving are implicit in module carrying-things. We require all sorts and functions 
appearing in a module to be either explicitly or implicitly declared in that module. 
By means of the module dependency construct, a theory of ACM. can be structured 
into a hierarchy of modules. The dependency relation of this hierarchy should form 
a DAG. Now we define the body of the new module: 

sort declarations 

carriahles :: things 
carry :: move 

attributes 

carried-object : carriahles 

Note that, since carry is dehned as a special case of move, it automatically inherits 
the attributes of move; hence those attributes do not have to be repeated in the 
declaration of carry. Next, the module contains the declarations of functions: 

function declarations 
fluents 
basic 

total holding : agents x things —>■ booleans 

deflned 

is-held : things —>■ booleans 
and the new axioms: 

axioms 

loc-in{C) = P if holding{T, C), 
loc-in{T) = P. 
loc-in{T) = P if holding{T, C), 
loc-in{C) = P. 

is-held{X) if holding{T, X). 

impossible occurs{X) if instance{X, move), 

actor(X) = A, 
is-held{A). 

impossible occurs{X) if instance{X, carry), 

actor(X) = A, 
carried-object (X) = C, 

-^holding{A, C). 

The hrst two axioms say that an agent and an object he is holding have the same 
location. The next defines fluent is-held{X) - object X is held by someone or 
something. The first executability condition states that to move an actor should be 
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free (i.e., not held). The second states that it is impossible to carry a thing without 
holding it. 

Structuring a theory of ACM into a hierarchy of modules has several advantages. 
First, this supports the stepwise development of a knowledge base by allowing parts 
of its theory to be developed and tested independently from other parts. Second, 
it increases the readability of ACM theories, due to the more manageable size 
of their modulesj^ And finally, this approach facilitates the creation of knowledge 
libraries. Theories containing very general information can be stored in a library and 
imported from there when constructing system descriptions. For instance, imagine 
that our motion theory is stored in a library called commonsenseJibrary. The 
system description travel could then be re-written by importing this theory as 
follows: 

system description travel 

import theory motion from commonsenseJibrary 
structure BobmndMohn 
{structure body) 

We hope that these examples gave the reader some insight into the meaning 
of theories of ACM that have more than one module. The accurate semantics for 
such a theory T is given by its Battening, i.e., by translating T into the unimodular 
theory with the same intuitive meaning. 

First, we will give the semantics of theories satisfying the semantic conditions 
given in the following definition, theories that we call semantically coherent. 

Definition 11 {Semantically Coherent Theory) 

A theory of ACM is semantically coherent if it satisfies the following conditions: 

• All sorts and functions appearing in a module of T are (explicitly or implicitly) 
declared in that module. 

• The module hierarchy of T dehned by relation “depends on” forms a DAG, 
G. (The nodes of G correspond to modules of T. An arc (M2, Mi) is in G if 
and only if module M2 contains the statement “depends on Mi”.) 

• No two modules of a theory contain different declarations of the same sort or 
the same function name. 

The last condition in Definition HD can be weakened to allow the use of the same 
name for a function and its restriction on a smaller sort. This and other similar 
features however can somewhat distract from the main ideas of ACM and will not 
be included in the original version of ACM. 

The flattening f{T) of an ACM theory T is constructed by the following algo¬ 
rithm: 

1 . Select modules Mi and M2 of T such that Mi contains the statement “depends 
on M2”. 

® For greater readability, we recommend maintaining a balance between a manageable module 

size and a relatively shallow module dependence hierarchy. 
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2. Replace Mi and M 2 by the new module M obtained by uniting depends on 
statements, sort declarations, object constant declarations, function declara¬ 
tions, and axioms of M 2 with those of Mi. 

3. Remove the statement “depends on M 2 ” from M. 

4. Replace Mi and M 2 in all the statements of T of the form “depends on Mi” 
and “depends on M 2 ” by M. 

5. Repeat until no dependent modules exist. 

6. Construct a new module with declarations and axioms defined as unions of 
the corresponding declarations and axioms of the remaining modules. 

7. Return the resulting unimodule theory f{T). 

The second condition in Definition im guarantees that the algorithm will termi¬ 
nate. The first and second conditions ensure that the result of the algorithm does 
not contain the depends on statement and that all sorts and functions within mod¬ 
ule M of step 2 have unique (explicit or implicit) declarations. Thanks to condition 
three this property is preserved by step 6 of the algorithm and hence /(T) is indeed 
a unimodule theory. 

As expected, the semantics of an ACM. theory T with more than one module is 
given by the semantics of the unimodule theory f(T). 

For illustrative purposes we give the result of applying the flattening algorithm 
to the motion theory given above: 
theory flat_motion 
module flat-motion 

sort declarations 

points, things :: universe 
agents, carriables :: things 

move :: actions 
attributes 

actor : agents 
origin : points 
dest : points 

carry :: move 

attributes 

carried-object : carriables 

function declarations 
statics 
basic 

symmetric-Connectivity : booleans 
transitive-Connectivity : booleans 

fluents 

basic 

total loc-in : things —>■ points 

total holding : agents x things —> booleans 

connected : points x points —>■ booleans 
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defined 

is-held : things —>■ booleans 

axioms 

occursiyX) causes loc-in{A) = D if instance{X, move), 

actor{X) = d, dest{X) = D. 

connected(X, X). 

connected{X, Y) if connected{Y, X), symmetric-connectivity. 

—•connected{X, Y) if —^connected{Y,X)j symmetric-connectivity. 

connected{X, Z) if connected{X, Y), connected{Y, Z)y 

transitiv e-Connectivity. 

locJn{C) = P if holding{T, C)i loc-in{T) = P. 
loc-in{T) = P if holding{T, C)j loc-in{C) = P. 


is-held{C) 

if holding{T,C) 


impossible 

occurs (X) 

if 

instance{X, move), actor[X) = A, 
origin{X) ^ loc-in{A). 

impossible 

occurs (X) 

if 

instance{X, move), actor(X) = A, 
dest{X) = loc-in{A). 

impossible 

occurs (X) 

if 

instance{X, move), actor{X) = A, 
loc-in(A) = 0, dest{X) = D, 

^connected{0, D). 

impossible 

occurs (X) 

if 

instance{X, move), 
actor{X) = A, is-held{A). 

impossible 

occurs (X) 

if 

instance{X, carry), actor{X) = A, 
carried-object{X) = C, Molding{A. 


For readability, we selected the same names for the theory and its module. This 
theory will be used in [Appendix C[ for the purpose of comparing ACM and MAD. 

Finally, the semantics of a system description with a theory T consisting of 
multiple modules is given by the collection of models of the BAT defined by f{T) 
and the collection of interpretations defined by the system’s structure. 

This concludes our introduction to the syntax and semantics of ACM. 


4 Methodology of Language Use 

In this section we further illustrate the methodology of using ACM for knowledge 
representation and for solving various computational tasks. 


4.J Representing Knowledge in ACM 


We exemplify the methodology of representing knowledge in ACM by considering 
a benchmark commonsense example from the field of reasoning about action and 


change — the Monkey and Banana Problem (McCarthy 1963 McCarthy 1968). 


(Another, more realistic, example of the use of ACM can be found in Appendix B 
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Problem 1 {Monkey and Banana) 

A monkey is in a room. Suspended from the ceiling is a bunch of bananas, beyond 
the monkey’s reach. In the room there is also a box. The ceiling is just the right 
height so that a monkey standing on the box under the bananas can reach the 
bananas. The monkey can move around, carry other things around, climb on the 
box, and grasp the bananas. What is the best sequence of actions for the monkey 
to get the bananas? 

In accordance with the basic methodology of declarative programming, we will 
first represent knowledge about the problem domain and then reduce the problem’s 
solution to reasoning with this knowledge. Based on our current experience, we 
recommend to divide the process of representation into the following steps: 

Methodology of Creating Modular Representations in ATM.'. 

• Build a hierarchy of actions pertinent to the domain. 

• Starting from the top of the hierarchy gradually build and test modules cap¬ 
turing properties of its actions. If necessary, add general non-action modules 
(e.g. a module dehning a sequence of actions). Whenever feasible, use existing 
library modules. 

• Build a module main containing specific information needed for the problem 
solution. 

• Populate the hierarchy with the domain’s objects. 


Here are a few comments about the second step listed above: When deciding how 
many actions to describe in one module, consider balancing the size of the module 
with the depth of the (part of the) hierarchy that it captures; also consider the 
resulting depth of the module dependency hierarchy. For instance, an action and 
its opposite are normally included in the same module. So are actions that usually 
occur together and share common fluents and sorts. To facilitate the discovery of 
relevant library modules, we assume that a dictionary indexed by action classes 
will be available to knowledge engineers. Action classes will be associated with the 
library modules in which they are described. The signature and axioms of library 
modules will be viewable by the knowledge engineer. 

Let us illustrate the methodology by solving the Monkey and Banana problem. 
The story is clearly about an agent moving around, and grasping and carrying 
things between various points. The hierarchy of actions pertinent to the story is 
illustrated in Figure 

Note that, unlike other actions, action release does not explicitly appear in the 
story. However, it is often advisable to consider actions together with their oppo¬ 
sites, so our hierarchy contains release together with grasp. 

To gradually build a theory monkey-and-banana containing the knowledge needed 
to solve the Monkey and Banana problem, we start with selecting a root of the ac¬ 
tion hierarchy - in our case action move. The inheritance hierarchy pertinent to 
move appears in Figure We already discussed the module moving describing the 
properties of move. The theory consisting of this module can be tested on a number 
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Fig. 5. Action Hierarchy for the Monkey and Banana Problem 

of specific domains using ASP-based methods discussed in the next section. Next 
we select three actions carry, grasp, and release understood as move while hold¬ 
ing, take and hold, and stop holding respectively. Since these actions share a fluent 
holdin^and sorts things and agents, and since a things-carrying agent usually also 
executes actions grasp and release, knowledge about these actions can be put in the 
same module. To do that we extend the inheritance hierarchy by a subclass carri- 
ables of things and expand module carrying_things from section [3^ by information 
about another two actions. Sort declarations of carrying_things from |3.2| will now 
also include 

grasp :: actions 
attributes 

grasper : agents 
grasped-thing : things 

and 

release :: actions 
attributes 

releaser : agents 
released-thing : things 

The section function declarations of the new module will contain the additional 
function can_reach needed as a precondition for the executability of grasp. The 
function will be defined in terms of locations of things. 

defined 

can-reach : agents x things —>■ booleans 

The set of axioms will be expanded as follows. The first two axioms below describe 
the direct effects of our new actions: action grasp results in the grasper holding the 
thing he grasped; this is no longer true after the thing is released. 
occurs {A) causes holding {X, Y) if instance (A, grasp), 

grasper {A) = X, 
grasped-thing (A) = Y. 

occurs {A) causes ^holding {X, Y) if instance{A, release), 

releaser{A) = X, 
released-thing [A) = Y. 


^ For simplicity we assume that an agent can only hold one thing at a time. A more general 
module may allow to grasp a collection of things up to a certain capacity. 
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The constraint 

^holding{X, Y 2 ) if holding{X, Yi), Yi ^ Y 2 
ensures that only one thing can be held at a time (and hence to grasp a thing an 
agent must have his hands free). 

This is followed by the executability conditions: one cannot grasp a thing he is 
already holding or a thing that is out of his reach; one cannot release a thing unless 
he is holding it. 

impossible occurs (^) if instance {A, grasp), 

grasper (A) = X, 
grasped-thing {A) = Y, 
holding{X, Y). 

impossible occurs (^) if instance (A, grasp), 

grasper (A) = X, 
grasped-thing {A) = Y, 

^can-reach{X, Y). 

impossible occurs(^) if instance{A, release), 

releaser(A) = X, 
released-thing (A) = Y, 

-^holding{X, Y). 

We also need a simple definition of can-reach - an agent can always reach an object 
he shares a location with. 

can-reach)M, 0) if loc-in{M) = loc-in{0). 

This definition will later be expanded to describe the specific geometry of our 
domain. 

This completes our construction of the new module carrying-things. 

After testing the theory consisting of moving and carrying-things we proceed to 
constructing a new module, climbing, which axiomatizes action climb understood 
as moving from the bottom of a thing to its top. We assume that one can climb 
only on tops of a special type of things called elevations, which will be added to 
our hierarchy as a subset of things. The corresponding declarations look as follows: 
module climbing 

depends on moving 

sort declarations 

elevations :: things 
climb :: move 
attributes 

elevation : elevations 

Now we introduce notation for points associated with the tops of elevations. The 
points are represented by object constants of the form top{E) where E is an eleva¬ 
tion. In ACA4 this is expressed by the following: 
object constants 

top (elevations) : points 
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(Notice that top here is not a function symbol; if e is an elevation, then top{e) is 
simply a point.) 

The module contains axioms saying that top{E) is the destination of climbing an 
elevation E-. 

dest{A) = top{E) if elevation{A) = E. 
and that a thing cannot be located on its own top: 
false if locJn{E) = top{E). 

The last axiom prohibits an attempt by an agent to climb an elevation from a 
distance: 

impossible occurs(X) if instance(X, climb), 

actor{X) = A, 
elevation{X) = 0, 
locJn{0) 7 ^ locJn{A). 

After testing the existing modules we concentrate on the specific information 
needed for the problem solution. It will be presented in a module called main. 

module main 

depends on carrying-things, climbing 

The main goal of the module is to define when the monkey can reach the banana. 
We start by dividing our sort points into three parts: Hoor-points, ceiling-points, 
and movable-points: 

sort declarations 

floor-points, ceiling-points, movable-points :: points 

where the latter correspond to tops of movable objects. We will see the use of these 
sorts a little later. Now we move to function declarations. The story is about three 
particular entities: the monkey, the banana, and the box. They will be defined as 
constants of our module. 

object constants 
monkey : agents 
box : carriables, elevations 
banana : carriables 

We will also need a function under, such that under{P, T) is true when point P is 
located under the thing T. Note that, if we consider this function to be defined for 
arbitrary points, it will be dynamic - under {top (box), banana) can be true in one 
state and false in another. This will force us to declare this function as a fluent, 
causing an unnecessary complication. Instead we define under for floor points only, 
which is sufficient for our purpose and is substantially simpler. 

function declarations 
statics 

basic under : floor-points x things —> booleans 
To define our function can-reach we need the following axiom: 
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axioms 

can_reach{monkey, banana) 


if locJn{box) = P, 
under{P, banana), 
loc An {monkey) = top{box). 


Finally, we need the following axioms 

for the basic fluent connected: 

connected {top {box), P) 

if 

loc-in{box) = P, 
instance{P, floor-points). 

^connected{top{box), P) 

if 

loc-in{box) ^ P, 
instance{P, floor-points). 

connected{Pi, P 2 ) 

if 

instance{Pi, floor-points), 
instance{P 2 , floor-points). 

^connected{Pi, P 2 ) 

if 

instance{Pi, ceiling-points), 
instance{P 2 , points), 

Pi + P 2 . 


This completes the construction of module main as well as theory monkey-and^banana 
that we will use to solve the Monkey and Banana problem. It is easy to see that 


the theory is semantically coherent, as it satisfies the conditions in Definition 11 


Figure and represent the sort hierarchy and module hierarchy of this theory, 
respectively. 



Fig. 6. Sort Hierarchy for the Monkey and Banana Problem 

To complete the description of our domain we introduce the structure containing 
three points located on the floor of the room and one point located on the ceiling, 
as well as movable points and particular actions mentioned in the story: 
structure monkey-and-banana 

instances 

under-banana, initial-monkey, initial-box in floor -points 
initial-banana in ceiling-points 
top{box) in movable-points 
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Fig. 7. Module Hierarchy for the Monkey and Banana Problem 

move{P) in move where instance{P, points) 
actor = monkey 
dest = P 

carry{hox, P) in carry where instance{P, floor-points) 
actor = monkey 
carried-object = box 
dest = P 

grasp{C) in grasp where instance{C, carriables) 
grasper = monkey 
grasped-thing = C 

release{C) in release where instance{C, carriables) 
releaser = monkey 
released-thing = C 

climb{box) in climb 
actor = monkey 
elevation = box 

values of statics 

under {under-banana, banana), 
symmetric-connectivity. 
transitive-Connectivity. 

The structure specifies that the relation connected is symmetric, but not transitive. 
The latter prevents the monkey from moving from its initial location directly on 
top of the box. 

The theory and structure described above can be combined into a system de¬ 
scription monkey-Snid-hanana as follows: 

system description monkey-and-banana-problem 
theory monkey-and-banana 

import motion from commonsense-library 
module main 

{module body) 
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structure monkey-and^banana 
{structure body) 

Note that the import statement above is a directive to import all of the modules 
of the library theory motion into the theory monkey-and-banana. 

The system describes a unique hierarchy and a unique transition diagram, r. 
Note that the hierarchy contains properly typed constants monkey, box, and banana 
declared in our module main] and that some of our functions, e.g. under, are partial. 

It is not difficult to check that there is a path in r that starts with the initial 
state of our problem and is generated by actions move{initial-box), grasp{box), 
carry {box, under-banana), release{box), climb{box), grasp {banana). The final state 
of this path will contain a fluent holding {monkey, banana). In the next section we 
discuss how ASP based reasoning can be used to automatically find such sequences. 


4-2 ACMl’s Use in Solving Computational Tasks 

A system description of ACM. describes a collection of transition diagrams that 
specifies some dynamic system. System descriptions can be used to solve computa¬ 
tional tasks such as temporal projection or planning, using a methodology similar 
to that developed for non-modular action languages like AC (see, for instance, 
(Gelfond and Kahl 20141). 


4 . 2.1 Temporal Projection 


Normally, system descriptions of ACM are used in conjunction with the description 
of the system’s recorded history — a collection of facts about the values of fluents 
and the occurrences of actions at different time steps in a trajectory. (Since we 
are only dealing with discrete systems such steps are represented by non-negative 
integers). Together, the system description and the history define the collection of 
possible trajectories of the system up to the current step. In our methodology of 
solving temporal projection tasks, possible trajectories are obtained by computing 
the answer sets of a logic program. To formally describe this methodology, we need 
the following definitions. 


Definition 12 {History - adapted from (Balduccini and Gelfond 2003dl^ ) 

By the recorded history r„ of a system description D up to time step n we mean 
a collection of observations, i.e., facts of the form: 


1. observed{f{t), v,i) - fluent /(I) was observed to have value v at time step i, 
where 0 < i < n. 

2. happened{a, i) - action a was observed to happen at time step i, where 0 < 
i < n. 


(There are two small differences between this and the definition of a history by 
Balduccini and Gelfond ( 2003a| ): the latter only allows boolean fluents and observa¬ 
tions that have the form observed{l, i) where I is a fluent or its negation. Similarly 
for the next definitions in this subsection.) 
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We say that the initial situation of r„ is complete if, for every user-defined basic 
fluent / and any sequence of ground terms t such that observed{domf(i), true, 0) G 
r„, r„ also contains a fact of the form observed{f(i), v,0). 


Example 9 (History) 

A possible recorded history for the system description monkey mnd-banana^problem 
in Section 4.1 may look as follows: 


hi =def {observed(loc-in(monkey), initial-monkey,0), 
observed(loc-in(box), initial-box, 0), 
happened(move(initial-box), 0)} 


which says that, initially, the monkey was at point initial-monkey and the box was 
at initial-box] the monkey went to the initial location of the box. 


The semantics of a history r„ is given by the following definition: 


Definition 13 (Model of a History - adapted from 


(Balduccini and Gelfond 2003a\l) 


Let r„ be a history of a system description D up to time step n. 

(a) A trajectory (cto, Cq, CTi, ..., a„_i, tT„) is a model of r„ if: 

1. ai = {a : happened(a, i) G r„}, for every 0 < i < n. 

2. if observed(f(t), v, i) G r„ then f(t) = v G (Ji, for every Q < i < n. 

(b) r„ is consistent if it has a model. 

(c) An atom f(t) = v holds in a model M of Tn, at time 0 < i < n if f (t) = v G Oi] 
A literal f(t)^v holds in a model M of r„ at time 0 < « < u if domf(t) = 
true G Ui and f(t) = v^ai] 

r„ entails a literal I at time step 0 < « < u if, for every model M of r„, I 
holds in M. 


Example 10 (Model of a History) 

History Ti from Example]^ is consistent. Its model is the trajectory: 

M =({ loc-in(monkey) = initial-monkey, loc-in(box) = initial-box, ... }, 
move (initial-box), 

{ loc-in(monkey) = initial-box, loc-in(box) = initial-box, ... })• 

(We do not show the values of connected since they are unchanged by our actions). 
Ti entails, for example, loc-in(monkey) = initial-box at time step 1. 

Note that a consistent history may have more than one model if non-deterministic 
actions are involved or the initial situation is not complete. 


Next, we define some useful vocabulary. 






38 


Daniela Inclezan and Michael Gelfond 


Definition I 4 {Set of Literals Defining a Sequence - adapted from 


(Balduccini and Gelfond 2003a j) 


Let r„ be a history of D and ^ be a set of literals over signature S. We say that 
A defines the sequence 

((To, ttg: ^1: ■ • ■ : ^n — 1: ^n) 

if: 

, , cTi = {f{to,... ,tn) = t : /(to, ■ ■ ■ ,tn) = t £ A and / is a static or attribute} U 
{/(to,..., t„) = t : /(to ,... ,tn,i) = t € A and / is a fluent} 
for any 0 < i < n, and 

(b) at = {a : occurs{a, k) S A} for any 0 < k < n. 


Definition 15 {Program Dtp - adapted from ^Balduccini and Gelfond 2003a j) 

If r„ is a history of system description D up to time step n, then by Dtp we denote 
the ASPjf} program constructed as follows: 


1. For every action a such that happened{a, i) G r„, Dtp contains: 
occurs{a, i) ■(— happened{a, i)- 

2. For every expression observed{f{f), ?;,0) G r„, Dtp contains: 
ffi, 0) = V G- observed{f{t), v, 0)- 

3. For every expression observed{f ft) , 11 , t) € F„, * > 0, Dtp contains the reality 
check axiom: 

•(— observed{f (t), vfi), 
domffit, i), 

/(t, i) V- 


Our methodology of finding trajectories by computing answer sets of a logic 
program is designed for system descriptions that match the intuition that defined 
functions are only shorthands, and their values are fully determined by those of 
basic statics and fluents. We call such system descriptions well-founded and define 
them formally as follows. 


Definition 16 {Well-founded System Description - adapted from 


(Gelfond and Inclezan 201^) 


Let I? be a system description whose theory encodes the BAT theory T, and whose 
structure defines a collection S of models of T.D is well-founded if, for every model 
j\4 in S, and every interpretation I with static part A4, the program Sx (defined 


as in Section 2.3) has at most one answer set. 


The system description monkey-and-banana-problem from Section |4.1| is well- 
founded. An example of a system description that is not well-founded is n-W-f 


shown below and adapted from (Gelfond and Inclezan 2013). The two defined fluents 


of n-W-f are not defined in terms of basic statics or fluents but rather in terms of 
one another by mutually recursive axioms. 
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system description n^wj 
theory n^wj 
module main 

sort declarations 
c :: universe 
fluent declarations 
deflned 

f : c ^ booleans 
g \ c ^ booleans 
axioms 

fix) if ^g{X). 
g{X) if -/(X). 
structure n.w.f 
instances 

a; in c 


In the case of the non-modular action language AC^ there is a known syntactic 


condition that guarantees that a system description is well-founded (Gelfond and 


Inclezan 2013). This condition can be easily expanded to ACM due to close con¬ 


nections between ACM and AC. 


Trajectories of a dynamic system specified by a well-founded system description 
are computed using a logic program 11 that consists of the ASP{f} encoding of the 
system description, the system’s recorded history, and the program Cltp connecting 
the recorded history with the system description. 

To simplify the presentation, in what follows we limit ourselves to well-founded 
system descriptions that describe domains in which there is complete information 
about the sort memberships of objects of the domainj^ Let us consider system 
description V that meets this requirement, and let Ad be a model of V’s theory. 
Then, the program Pm obtained from the theory of V and M as described in 


section 2.3 will be used as the ASP{f} encoding of V. 


Definition 17 {Program Iltp{D)) 

If r„ is a history of V up to step n, then AtplV) is the logic program defined as 

Atp{V) =def Pm U Pn U VLtp 

such that the sort step in the signature of AtpiV) ranges over the set {0,..., n}. 


Proposition 1 

If r„ is a consistent history of D such that the initial situation of r„ is complete, 
then M is a model of r„ iff M is defined by some answer set of program I{tp{D). 


This is not a serious restriction; it can be easily lifted by adding to the ASP encoding of the 
AC^A system description rules of the type 

zs_a(x, c) or —^is-a(x^ c) 

for every object x and every source node c in the hierarchy of sorts. 
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This proposition can be proven using techniques similar to the ones employed in 
Lemma 5 in ( Balduccini and Gelfond 2003a[ )p] 

We used the above methodology of solving temporal projection tasks to cre¬ 
ate a question answering system in the context of the Digital Aristotle project 
(Inclezan and Gelfond 2011). Our system was capable of answering complex end- 
of-the-chapter questions on cell division, extracted from a well-known biology text¬ 
book. 


4-2.2 Planning 

In planning problems, in addition to the history of the dynamic system up to the 
current time point, information about the goal to be achieved is also provided. 
Given a system description of ACA4 whose theory describes a basic action theory 
T, a goal is a collection G of ground user-defined fluent literals over the signature 
of T. For instance, for the Monkey and Banana problem in Section |4.1[ the goal 
is Gmb = {holding{monkey, banana)}. Goals can be encoded as logic programming 
rules, as described in the following definition: 

Definition 18 {Goal Encoding) 

Given a goal G, we call encoding of G, denoted by lp{G) the rule 

goal{I) •(— body 

where body is defined as follows: 

body =def {f{t,I) = V : f{t) = v S G} U {f{t,I)^v : f{t)^v G G}- 


In order to solve planning problems, a slightly different logic programming module 
will be needed than for solving temporal projection tasks. This module is defined in 


CR-Prolog (Balduccini and Gelfond 2003b |, an extension of ASP designed to han¬ 


dle, among other things, rare events. In addition to regular ASP rules, programs in 
CR-Prolog may contain consistency restoring rules that have the following syntax: 


hi or ... or hk 




; • ■ • : I'm j not ljfi + 1 ; ■ • ■ ; nOt 


Informally, this statement says that an intelligent agent who believes li,... Am and 
has no reason to believe Im+i, - An niay believe one of /li’s, 1 < * < fc, but only 
if no consistent set of beliefs can be formed otherwise. For the formal semantics of 


CR-Prolog, we refer the reader to (Balduccini and Gelfond 2003b). An extension of 


ASP{f} by consistency restoring rules is defined in (Balduccini and Gelfond 2012). 


Solvers for CR-Prolog are described in (Balduccini 2007) and (Balai et al. 2012). 


Definition 19 {Planning Module (Balduccini 2004: Gelfond and Kahl 2014])) 


® The proof and text of Lemma 5 appear on page 29 of the version of ijBalduccini and Gelfond] 
|2003a^ available at http://arxiv.org/pdf/cs/0312040vl.pdf. Retrieved on August 3, 2014. 
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Given a goal G, the planning module VLpi extends module dtp from Section 4.2.1 


by the following rules: 


rx{A,I)'- occurs{A,I) 

smtg-happened ( I) 


success 


<— goal(I), I < n 
■(— not success 

instance{A, actions) 

■<r- occurs{A,I) 

•(— not smtg-happened(I) 


smtg-happened{I + !)• 


dpi computes minimal plans of maximum length n by the use of the consistency 
restoring rule ri and the two regular rules that follow it. 

The actual program for computing plans is constructed similarly as before. 
Definition 20 {Program Iipi{V)) 

If r„ is a history of V up to step n and G is a goal over V, then ApiiV, G) is the 
logic program defined as 


Api{'D, G) =def Pm U r„ U dpi U lp{G) 


such that the sort step in the signature of XlpiiV, G) ranges over the set {0,..., n}. 

The following proposition specifies how answer sets of the logic program defined 
above can be mapped into plans for achieving given goals. 

Proposition 2 

If r„ is a consistent history of D such that the initial situation of r„ is complete 
and G is a goal over I?, then the collection of atoms of the form occurs {a, i) from 
an answer set of Ilpi{D, G) defines a minimal plan for achieving goal G, and every 
such plan is represented by the occurs atoms of some answer set of IVpi{V, G). 

Example 11 {Planning in the Monkey and Banana Problem) 

If we consider the Monkey and Banana problem with the initial situation 

Cmb = { observed{loc-in{monkey), mitial-monkey,0), 
observed{loc-in{box), initial-box, 0) 

and the goal 

Grab = {holding{monkey, banana)} 

defined earlier, then an answer set of program Ilpi{monkey-and-banana-problem, Gmb) 
will contain the following occurs atoms: 

{ occurs{move{initial-box),0), occurs{grasp{box),l), 

occurs {carry {box, under-banana), 2), occurs{release{box),3), 
occurs {climb {box), 4), occurs{grasp{banana),5) } 

defining a minimal plan ( move{initial-box), grasp{box), carry{box, under-banana), 
release{box), climb{box), grasp{banana) ) resulting in the monkey holding the ba¬ 
nana at time step 6. The program will also find the second minimal plan in which 
carry {box, under-banana) at step 2 is replaced by move{under-banana). Since the 
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first action is more specific than the second one the first plan seems to be preferable. 
This can easily be expressed by a slightly modified planning module allowing only 
most specific actions. 


5 Related Work 


Many ideas of ACM, such as the notions of action language, module, sort hierar¬ 
chy, attribute defined as a partial function, etc., are well-known from the literature 
on programming languages and knowledge representation. Some of the basic refer¬ 
ences to these notions were given in the text. In this section we briefly comment 
on the relationship between ACM and the previously existing modular action lan- 


guages MAD (Lifschitz and Ren 2006 Erdogan and Lifschitz 2006 

Desai and Singh 

2007), TAL-C ( 

Gustafsson and Kvarnstrdm 2004), and the earlier version of ACM 

(Gelfond and Inclezan 2009). 



We start with summarizing the differences between the two versions of ACM. 
There are a number of changes in the syntax of the language. For instance, theories 
of the new version of ACM may contain non-boolean fluent^^ and constants that 
substantially simplify ACM’s use for knowledge representation. Axioms of a theory, 
which in the old version were included in the theory’s declarations, are now put in 
a separate section of the theory. This removed the problem of deciding which fluent 
or action declaration should contain an axiom, and improved the readability of the 
language. There are also substantial improvements in the syntax of axioms, etc. 
Another collection of changes is related to the semantics of the language. First, the 
new semantics, based on the notions of basic action theory and its models, clarified 
and generalized the old definition and allowed the introduction of the entailment 
relation. Second, the semantics is now defined for structures with possibly under¬ 
specified membership relations of its objects in the sort hierarchy, which simplifies 
reasoning with incomplete information. Third, the semantics was initially given in 


terms of action language AC (Turner 1997 Baral and Gelfond 20001, where the 


AC semantics is defined by a translation into ASP; now, we give the semantics of 
our language directly in ASP - in fact, in an extension of ASP with non-Herbrand 


functions, ASP{f} (Balduccini 2013). We believe that decoupling ACM from AC 
will allow us to combine ACM with action languages that correspond to other 
intuitions. 


Another modular language is TAL-C (Gustafsson and Kvarnstrdm 2004), which 


allows definitions of classes of objects that are somewhat similar to those in ACM. 
TAL-C, however, seems to have more ambitious goals: the language is used to 
describe and reason about various dynamic scenarios, whereas in ACM the de¬ 
scription of a scenario and that of reasoning tasks are not viewed as part of the 
language. The more rigid structure of ACM supports the separation of concerns 
design principle and makes it easier to give a formal semantics of the language. 


In the field of lo gic programming, an early discussion on the introduction of functions appears 
in ([Hanus 1994[|. 
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These differences led to vastly distinct knowledge representation styles reflected in 
these languages. 

There are smaller, but still very substantial, differences between ACM and MAD. 
The two languages are based on non-modular action languages with substantially 
different semantics and underlying assumptions, use very different constructs for 
creating modules and for defining actions as special cases, etc. A more detailed 
comparison between the two approaches can be found in [Appendix C[ 


6 Conclusions and Future Work 


In this paper, we have presented a methodology of representing and reasoning 
about dynamic systems. A knowledge engineer following this methodology starts 
with finding a proper generalization of a particular dynamic system D, finds the 
sorts of objects pertinent to this generalization, organizes these sorts into an inher¬ 
itance hierarchy and uses causal laws, definitions, and executability conditions to 
specify relevant properties of the sorts elements. The resulting basic action theory, 
say T, gives the first mathematical model of the system. In the next step of the 
development, a knowledge engineer refines this model by providing its description 
in the high level action language ACM . The language has means for precisely rep¬ 
resenting the signature of T including its sort hierarchy. It is characterized by a 
modular structure, which improves readability and supports the step-wise develop¬ 
ment of a knowledge base, reuse of knowledge, and creation of knowledge libraries. 
ACM’s description of T can be used to specify multiple dynamic systems with dif¬ 
ferent collections of objects and statics. A particular system D can be specified by 
populating sorts of T by objects of D and defining values of D's statics. This step is 
also supported by ACM , which clearly separates the definition of sorts of objects of 
the domain (given in T) from the definition of instances of these sorts (given by an 
ACM structure). This, together with the means for defining objects of the domain 
as special cases of previously defined ones, facilitates the stepwise development and 
testing of the knowledge base and improves its elaboration tolerance. 

A close relationship between ACM and Answer Set Programming allows the use 
of ACM system descriptions for non-trivial reasoning problems including temporal 
projection, planning, and diagnosis. This is done by an automatic translation of 
an ACM system description into logic programs whose answer sets correspond to 
solutions of the corresponding problems. The existence of efficient answer set solvers 
that allow to compute these answer sets substantially increases the practical value 
of this approach. 

The above methodology has been illustrated by two examples: the well-known 
benchmark Monkey and Banana problem and a more practical problem of formal¬ 
ization of knowledge and answering questions about biological processes such as 


the cell division (see Appendix B). It is possible (and even likely) that further ex¬ 
perience with ACM will suggest some useful extensions of the language but the 
authors believe that the version presented in this paper will remain relatively stable 
and provide a good basis for such extensions. 
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We conclude by briefly outlining a number of questions about ACM. that we 
believe deserve further investigation: 

• Investigating mathematical properties of ACM and its entailment relation. 
This includes but is not limited to studying compositional properties of ACM 
modules, axiomatizing its entailment relation, and establishing a closer rela¬ 
tionship between ACM and modular logic programming. 

• Developing more efficient reasoning algorithms exploiting the modular struc¬ 
ture of ACM's theories and the available information about the sorts of 
objects in ACM'"a system descriptions. Among other things it is worth inves¬ 
tigating the possible use of modular logic programming as well as the methods 


from (Gebser et al. 2011), (Gebser et al. 2011), and (Balai et al. 20121. It may 


also be interesting to see if the implementation could benefit from hybrid ap¬ 


proaches combining description logics with ASP (e.g. (Eiter et al. 20081) or 
from typed logic programming (e.g. ( Pfenning 1992| ). 

Designing and implementing a development environment to facilitate the use 
of ACM in applications, the creation and storage of libraries, and the testing 
and debugging of theories and modules. 

Extending ACM with the capability of representing knowledge about hybrid 
domains, i.e., domains that allow both discrete and continuous change. In 
particular, it may be a good idea to combine ACM with action language H 


(Chintabathina et al. 2005 Chintabathina 20121. 


Developing the core of an ACM library of commonsense knowledge. (In par¬ 
ticular we would like to create an ACM library module containing a theory 


of intentions in the style of (Blount et al. 2014).) This work would allow us 
to extend our study on the capabilities of our language, while simultaneously 
providing a tool for members of our community to use when building their 
reasoning systems. 
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Appendix A Grammar of ACM. 

(boolean) true | false 

(non-Zero-digit) 1 | • • • | 9 

(digit) 0 | (non-zero-digit) 

(lowercase-letter) a | • • • | z 

(uppercase-letter) A | • • • | Z 

(letter) (lowercase-letter) \ (uppercase-letter) 

(identifier) (lowercase-letter) \ (identifier)(letter) \ (identifier)(digit) 

(variable) (uppercase-letter) \ (variable)(letter) \ (variable)(digit) 

(positive-integer) (non-zero-digit) \ (positive-integer)(digit) 

(integer) 0 | (positive-integer) \ — (positive-integer) 

(arithmetic-op) + | — | * | / | mod 

(comparison-rel) > | > | < | < 

(arithmetic-rel) (eg) | (neq) \ (comparison-rel) 

(basic-arithmetic-term) (variable) \ (identifier) \ (integer) 

(basic-term) (basic-arithmetic-term) \ (boolean) 

(function-term) (identifier)(function-arg.s) 

(function-args) {(term)(remainder-function-urgs)) 

(remainder-function-args) e| , (term)(remainder-function-args) 

(arithmetic-term) (basic-arithmetic-term)(arithmetic-op)(basic-arithmetic-term) 

(term) (basic-term) \ (arithmetic-term) 

(positive-function-literal) (function-term) \ (function-term)(eq)(term) 

(function-literal) (positive-function-literal) \ -^(function-term) \ 

(function-term) (neq) (term) 

(literal) (function-literal) \ (arithmetic-term)(arithmetic-rel)(arithmetic-term) 

(var-id) (variable) \ (identifier) 

(body) e | , (literal)(body) 

(dynamic-Causal-law) occ\n:s((var-id)) causes (positive-function-literal) if 

instance(( var-id), ( var-id) ) ( body) • 

(state-Constraint) (sc-head) if (body)- 
(sc-head) false | (positive-function-literal) 

(definition) (function-term) if (body)- 
(executability-Condition) imposible occms((var-id)) if 

instance(( var-id), (var-id)) (extended-body)- 
(extended-body) e \ , (literal)(body) \ , occm:s((var-id))(extended-body) \ 

, ^occmcs((var-id )) ( extended-body) 

(system-description) system description (identifier) (theory)(structure) 

(theory) theory (identifier) (set-of-modules) \ import (identifier) from (identifier) 

(set-of-modules) (module)(remainder-modules) 

(remainder-modules) e \ (module)(remainder-modules) 

(module) module (identifier) (module-body) \ 

import (identifier).(identifier) from (identifier) 

(module-body) (sort-declarations)(constant-declarations)(function-declarations)(axioms) 
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{sort-declarations) e \ sort declarations {onesort-decl) {remaindersort-declarations) 

{remaindersort-declarations) e \ {onesort-decl) {remaindersort-declarations) 

{onesort-decl) {identifier){remaindersorts) :: {sort-name){remaindersort-names){attributes) 

{remaindersorts) e | , {identifier){remaindersorts) 

{remaindersort-names) e \ , {sort-name){remaindersorts) 

{sort-name) {identifier) \ [ {integer)..{integer) ] 

{attributes) e \ attributes {one-attribute-decl){remainder-attribute-declarations) 

{one-attribute-decl) {identifier) : {arguments){identifier) 

{arguments) e \ {identifier){remainder-args) —>■ 

{remainder-args) e | x {identifier) {remainder-args) 

{remainder-attribute-declarations) e | 

{one-attribute-decl) {remainder-attribute-declarations) 

{constant-declarations) e \ object constants {one-constant-decl){remainder-constant-declarations) 
{one-Constant-decl) {identifier){constant-params) : {identifier) 

{remainder-Constant-declarations) e \ {one-constant-decl){remainder-constant-declarations) 

{constant-params) ( {identifier){remainder-constant-params) ) 

{remainder-Constant-params) e | , {identifier) {remainder-constant-params) 

{function-declarations) e \ function declarations {static-declarations) {fluent-declarations) 

{static-declarations) e \ statics {basic-function-declarations){defined-function-declarations) 

{fluent-declarations) e \ fluents {basic-function-declarations){defined-function-declarations) 

{ba.sic-function-declarations) e \ basic {one-function-decl){remainder-function-declarations) 
{defined-function-declarations) e \ defined {one-function-decl){remainder-function-declarations) 

{one-function-decl) {total-partial){one-f-decl) 

{total-partial) e \ total 

{onc-f-decl) {identifier) : {identifier){remainder-args) —)■ {identifier) 

{remainder-function-declarations) e | {one-function-decl){remainder-function-declarations) 

{axioms) e | axioms {one-axiom){remainder-axioms) 

{one-axiom) {dynamic-causal-law) \ {state-constraint) \ {definition) \ {executability-condition) 

{remainder-axioms) e \ {axiom){remainder-axioms) 

{structure) structure {identifier){constant-defs){instance-defs){statics-defs) 

{constant-defs) e \ constants {one-constant-def){remainder-constant-defs) 

{one-Constant-def) {identifier) = {value) 

{value) {identifier) \ {boolean) \ {integer) 

{remainder-Constant-defs) e | {one-constant-def){remainder-constant-defs) 

{instance-defs) e \ instances {one-instance-def){remainder-instance-defs) 

{one-instance-def) {object-name){remainder-object-names) in 

{identifier) {cond) {attribute-defs) 

{object-name) {identifier){object-args) 

{object-args) e \ {{basic-term){remainder-object-args)) 

{remainder-object-args) e| , {basic-term){remainder-object-args) 

{remainder-object-names) e| , {object-name){remainder-object-names) 

{cond) e | where {literal){remainder-Cond) 

{remainder-Cond) e | , {literal) {remainder-Cond) 
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{attribute-defs) e \ {one-attributeMef){remainder^attributeMefs) 

{one-attribute-def) {identifier) {objectmrgs) = {basicAerm) 

{statics-defs) e| values of statics {onestatic-def){remainderstatics-defs) 
{onestatic-def) {function-literal) if {body)- 

{remainderstatics-defs) e \ {onestatic-def){remainderstatics-defs) 
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Appendix B ACMi and the Digital Aristotle 


The reader may have noticed that the ACM examples included in the body of 
the paper are relatively small, which is understandable given that their purpose 
was to illustrate the syntax and semantics of our language and the methodology 
of representing knowledge in ACM. In this section, we show how the reuse of 
knowledge in ACM can potentially lead to the creation of larger practical systems. 
We present an application of our language to the task of question answering, in 
which ACM’’?! conceptual separation between an abstract theory and its structure 
played an important role in the reuse of knowledge. The signature of the theory 
and its structure provided the vocabulary for the logic form translation of facts 
expressed in natural language while the theory axioms contained the background 
knowledge needed for producing answers. The theory representing the biological 
domain remained unchanged and was coupled with various structures corresponding 
to particular questions and representing the domain at different levels of granularity. 
In addition to demonstrating the reuse of knowledge in ACM , this application also 
shows the elaboration tolerance of our language, as only minor changes to the 
structure had to be made when the domain was viewed in more detail, while the 
theory stayed the same. In what follows, we present the application in more detail. 


After designing our language, we tested and confirmed its adequacy for knowl¬ 
edge representation in the context of a practical question answering application: 
Project Halo (2002-2013) sponsored by Vulcan Incj^The goal of Project Halo was 
the creation of a Digital Aristotle — “an application containing large volumes of 
scientific knowledge and capable of applying sophisticated problem-solving methods 
to answer novel questions” (Gunning et al. 20101. Initially, the Digital Aristotle was 
only able to reason and answer questions about static domains. It lacked a method¬ 
ology for answering questions about dynamic domains, as it was not clear how to 
represent and reason about such domains in the language of the Digital Aristotle. 
Our task within Project Halo was to create a methodology for answering questions 
about temporal projection in dynamic domains. We had two objectives. First, we 
wanted to see if the use of ACM for knowledge representation facilitated the task of 
encoding extensive amounts of scientific knowledge through its means for the reuse 
of knowledge. Second, we investigated whether provable correct and efficient logic 
programming algorithms could be developed to use the resulting ACM knowledge 
base in answering non-trivial questions. 

Our target scientific domain was biology, specifically the biological process of cell 
division (also called cell cycle). Cell cycle refers to the phases a cell goes through 
from its “birth” to its division into two daughter cells. Cells consist of a number of 
parts, which in turn consist of other parts (e.g., eukaryotic cells contain organelles, 
cytoplasm, and a nucleus; the nucleus contains chromosomes, and the description 
can continue with more detailed parts). The eukaryotic cell cycle consists of a growth 
phase (interphase) and a duplication/division phase (mitotic phase), both of which 
are conventionally described as sequences of sub-phases. Depending on the level 


http://www.allenai.org/TemplateGeneric.aspx?contentId=9 
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of detail of the description, these sub-phases may be simple events or sequences of 
other sub-phases (e.g., the mitotic phase is described in more detail as a sequence of 
two sub-phases: mitosis and cytokinesis; mitosis, in turn, can be seen as a sequence 
of five sub-phases, etc.). Certain chemicals, if introduced in the cell, can interfere 
with the ordered succession of events that is the cell cycle. 

In order to be useful in answering complex questions, the ACM representation 
of cell cycle had to capture (1) non-trivial specialized biological knowledge about 
the structure of the cell at different stages of the cell cycle and (2) the dynamics of 
naturally evolving process (such as cell cycle), which consist of a series of phases 
and sub-phases that follow one another in a specific order, unless interrupted. We 
represented such processes as sequences of actions intended by nature and used a 
commonsense theory of intentions {Baral and Gelfond 20051 to reason about them. 

Our ACM cell cycle knowledge base consisted of two library modules. One of 
them was a general commonsense module describing sequences, in particular se¬ 
quences of actions. The other module was a specialized one formalizing the biolog¬ 
ical phenomenon of cell division. We begin with the presentation of our common- 
sense module describing sequences, useful in modeling naturally evolving processes 
such as cell division. The equality component{S, N) = E appearing in the axioms of 
module sequence is supposed to be read as “the component of sequence S is E”. 
The library module sequence is stored in a general library called commonsenseAib. 


module sequence 
sort declarations 

sequences :: universe 

attributes 

length : positive-natural-numbers 
component : [0..length] —>■ universe 

action sequences :: sequences 

axioms 

false if component's, N) = E, 

instance{S, action sequences), 

Mnstance{E, actions), 

Mnstance{E, action sequences). 

The axiom ensures proper typing for the domain of an attribute component. 


Next, we present our formalization of cell cycle, given in a library module called 
basic-Cell-Cycle stored in a general cell-cycle-lib library. We started by modeling 
the eukaryotic cell, consisting of various parts that in turn consist of other parts. 
Together, they form a “part of” hierarchy, say Hceii, which can be viewed as a tree. 
Nodes of this hierarchy were captured by a new sort, types-of-parts, while links in 
the hierarchy were represented by an attribute, is-part-of, defined on elements of 
the new sort (e.g., is-part-of{X) — Y indicates that Y is the father of X in Hceii). 
We modeled the transitive closure of is-part-of by introducing a boolean function, 
part-of, where part-of{X, Y) is true if X is a descendant of Y in Hceii- 

In the type of questions we addressed, at any given stage of the cell cycle process. 
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all cells in the experimental sample had the same number of nuclei; similarly for 
the other inner components. As a result, we could assume that, at every stage 
and for each link from a child X to its parent Y in Hceii, this link was assigned 
a particular number indicating the number of elements of type X in one element 
of type Y. The states of our domain were described by a basic fluent, num : 
types-of-parts x types-of-parts —)■ natural-numbers, where num{Pi, P 2 ) = N holds 
if the number of elements of type Pi in one element of type P 2 is N . For instance, 
num{nucleus, cell) = 2 indicates that, at the current stage of the cell cycle, each 
cell in the environment has two nuclei. 

To describe the cell cycle we needed two action classes: duplicate and split. 
Duplicate, which acts upon an object that is an element from sort types-of-parts, 
doubles the number of every part of this kind present in the environment. Split 
also acts upon an object ranging over types-of .parts. An action a of this type with 
object{a) = Ci, where C2 is a child of Ci in H^eii, duplicates the number of elements 
of type Cl in the environment and cuts in half the number of elements of type C2 
in one element of type ci. For example, if the experimental environment consists 
of one cell with two nuclei, the occurrence of an instance a of action split with 
object{a) = cell increases the number of cells to two and decreases the number 
of nuclei per cells to one, thus resulting in an environment consisting of two cells 
with only one nucleus each. In addition to these two actions we had an exogenous 
action, prevent-duplication, with an attribute object with the range types-of .parts. 
The occurrence of an instance action a of prevent .duplication with object{a) = c 
nullifies the effects of duplication and splitting for the type c of parts. We made 
use of this exogenous action in representing external events that interfere with the 
normal succession of sub-phases of cell cycle. All this knowledge is represented by 
the following module: 

module basic .cell .cycle 

sort declarations 

types-of.parts :: universe 

attributes 

is-part-of : types .of .parts 

duplicate :: actions 
attributes 

object : types .of .parts 

split :: duplicate 

prevent.duplication :: actions 
attributes 

object : types .of .parts 

function declarations 

statics 

defined 

part-of : types .of .parts x types .of .parts —> booleans 
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fluents 

basic 

total num : types-of-parts x types-of -parts —)■ natural-numbers 
prevented-dupl : types-of -parts —>■ booleans 

axioms 


occurs(X) causes num{P2, Pi) = N2 


occurs(X) causes num{P2, Pi) = N2 


if instance{X, duplicate), 
object{X) = P2, 
is-part-of {P2) = Pi, 
num{P 2 , Pi) = Ni, 
Ni*2 = N2- 
if instance{X, split), 
object{X) = Pi, 
is-part-of {P2) = Pi, 
num{P 2 , Pi) = Ni, 
N2*2 = Ni- 


occurs{X) causes prevented-dupl{P) if instance{X, prevent-duplication), 

object{X) = P- 

part-of{Pi, P2) if is-part-of{Pi) = P 2 - 

part-of {Pi, P2) if is-part-of{Pi) = P3, 

part-of{P^,P2)- 

num{P, P) = 0- 

num{P^,Pi) = N if is-part-of{P3) = P2, 

part-of {P2, Pi), 
num{P 2 , Pi) = Ni, 
num{P 3 , P2) = N2, 


Ni ^ N2 = N- 


impossible occurs{X) if instance{X, duplicate), 

object{X) = P, 
prevented-dupl (P) • 


Any model of cell cycle consists of a theory importing the two library modules pre¬ 
sented above and a structure corresponding to the level of detail of that model. Let 
us consider a first model, in which we view cell cycle as a sequence consisting of inter¬ 
phase and the mitotic phase. This is represented in the structure by adding the at¬ 
tribute assignments component{\) = interphase and component{ 2 ) = mitotic-phase 
to the definition of instance cell-cycle. We remind the reader that such attribute 
assignments are read as “the 1®* component of cell-cycle is interphase” and “the 
2"*^ component of cell-cycle is mitotic-phase”. Interphase is considered an elemen¬ 
tary action, while the mitotic phase splits the cell into two. We limit our domain 
to cells contained in an experimental environment, called sample. 


system description cell-cycle{l) 
theory 

import module sequence from commonsense-lib 
import module basic-cell-cycle from cell-cycle-lib 
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structure 

instances 

sample in types-of-parts 
cell in types-of-parts 
is-part-of = sample 

cell-cycle in action sequences 
length = 2 

component (1) = interphase 
component{2) = mitotic-phase 

interphase in actions 

mitotic-phase in split 
object = cell 


This initial model of cell division is quite general. It was sufficient to answer a 
number of the questions targeted by the Digital Aristotle. There were, however, 
some questions which required a different model. 

Consider, for instance, the following question from (Campbell and Reece 2001): 


12.9. Text : In some organisms mitosis occurs without cytokinesis occurring. 
Question : How many cells will there be in the sample at the end of the 
cell cycle, and how many nuclei will each cell contain? 


To answer it, the system needed to know more about the structure of the cell 
and that of the mitotic phase. ATM. facilitated the creation of a refinement of our 
original model of cell division: a new system description, cell-cycle{2), was easily 
created by adding to the previous structure a few new instances: 
nucleus in types-of-parts 
is-part-of = cell 
mitosis in duplicate 
is-part_of = nucleus 
cytokinesis in split 
is-part_of = cell 

and replacing the old definition of the instance mitotic-phase by a new one: 
mitotic-phase in actionsequences 
length = 2 

component {!) = mitosis 
component{2) = cytokinesis 

Similarly, various other refinements of our original model of cell division contained 
the same theory as the original formalization; only the structure of our original 
model needed to be modified, in an elaboration tolerant way. Matching questions 
with models of cell division containing just the right amount of detail is computa¬ 
tionally advantageous and, in most cases, the matching can be done automatically. 

Our formalization of cell division illustrates ACM’s capabilities of creating large 
knowledge bases for practical systems through its mechanisms for reusing knowl¬ 
edge. In our example, the two modules that formed the theory were directly im- 
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ported from the library into the system description. This shows that our main goal 
for ACM - the reuse of knowledge - was successfully achieved. 

Additionally, the example demonstrates ACM ’s suitability for modeling not only 
commonsense dynamic systems, but also highly specialized, non-trivial domains. 
It shows the importance of creating and using libraries of knowledge in real-life 
applications, and it demonstrates the ease of elaborating initial formalizations of 
dynamic domains into more detailed ones. 


Our second task in Project Halo was to develop a proof-of-concept question an¬ 
swering system that used ACM formalizations of cell cycle in solving complex 
temporal projection questions like 12.9 above. To do that, we used the methodol¬ 
ogy described in Section 4.2, expanded by capabilities for reasoning about naturally 
evolving processes. This latter part was done by incorporating a theory of intentions 
(Baral and Gelfond 2005) and assuming that naturally evolving processes have the 
tendency (or the intention) to go through their sequence of phases in order, unless 
interrupted (e.g., we can say that a cell tends/ intends to go through its cell cycle, 
which it does unless unexpected events happen). 

In our question answering methodology, the structure of our ACM system de¬ 
scription for the cell cycle domain provided the vocabulary for translating the ques¬ 
tions expressed in natural language into a history. The theory of the system descrip¬ 
tion contained the axioms encoding the background knowledge needed to answer 
questions about the domain. 

As an example, the information given in the text of 12.9 above would be encoded 
by a history that contains the facts 


observed[num{cell, sample), 1,0) 
observed{num{nucleus, cell), 1,0) 
intend{celTcycle, 0) 
Mappened{cytokinesis, I) 


for every step I. Note that, unless otherwise specified, it would be assumed that 
the experimental sample consists of one cell with one nucleus. 

The query in 12.9 would be encoded by the ASP{f} rules: 

answeriyX, “cells per sample”) ^ lastMep{I), 

num{cell, sample, I) = X- 
answeriyX, “nuclei per cell”) ^ lastMep{I), 

num{nucleus, cell, I) = X- 

Our system, ACMAS, would solve the question answering problem by first gener¬ 
ating a logic program consisting of the above facts and rules encoding the history 
and query, respectively; the ASP{f} translation of the ACM system description 
celLcycle{2)-, and the temporal projection module described in Section 4.2. Then, 
the system would compute answer sets of this program, which correspond to answers 
to the question. For 12.9 there would be a unique answer set, containing: 
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intend{cytokinesis, 2) 
intend {cytokinesis, 3) 
intend ( cytokinesis , 4) 


-^occurs{cytokinesis, 2) 
—•occurs{cytokinesis, 3) 
-^occurs{cytokinesis, 4) 


These facts indicate that the unfulfillable intention of executing action cytokinesis 
persists forever. Additionally, the answer set would include atoms: 

answer{l, “cells per sample”) holds{val{num{cell, sample), 1), 2) 
answer{2, “nuclei per cell”) holds{val{num{nucleus, sample), 2), 2) 

last-step{2) holds{val{num{nucleus, cell), 2), 2) 

which indicate that at the end of the cell cycle there will be one cell in the sample, 
with two nuclei. This is in fact the correct answer to question 12.9. 

This question answering methodology and the methodology of reasoning about 
naturally evolving processes using intentions was successfully applied to other ques¬ 
tions about cell division. 



Modular Action Language ACM. 


55 


Appendix C Comparison between Languages ACM and MAD 


In this section we give an informal discussion of the relationship between ACM 


and the modular action language MAD (Lifschitz and Ren 2006 Erdogan and 


Lifschitz 2006). Both languages have similar goals but differ signihcantly in the 


proposed ways to achieve these goals. We believe that each language supports its 
own distinctive style of representing knowledge about actions and change. The 
difference starts with the non-modular languages that serve as the basis for ACM 
and MAD. The former is a modular expansion of action language AC. The latter 
expands action language C (Giunchiglia and Lifschitz 1998). Even though these 
languages have a lot in common (see (Gelfond and Lifschitz 2012)) they differ 
significantly in the underlying assumptions incorporated in their semantics. For 
example, the semantics of AC incorporates the Inertia Axiom, which says that 
“Things normally stay the same.” Language C is based on a different assumption 
- the Causality Principle - which says that “Everything true in the world must 


be caused.” Its underlying logical basis is causal logic (McCain and Turner 1997 


Giunchiglia et al. 2004). In C the inertia axiom for a literal I is expressed by a 


statement 


caused I if I after I, 

read as “there is a cause for I to hold after a transition if I holds both before and 
after the transition”. While AC allows two types of fluents - inertial and defined 
-, C can be used to dehne other types of fluents (e.g., default fluents that, unless 
otherwise stated, take on the hxed default values). The authors of this paper did not 
find these types of fluents to be particularly useful and, in accordance with their 
minimalist methodology, did not allow them in either AC or ACM. Of course, 
the question is not settled and our opinion can change with additional experience. 
On another hand, AC allows recursive state constraints and definitions, which are 
severely limited in C. There is a close relationship between ASP and C but, in our 
judgment, the distance between ASP and AC is smaller than that between ASP 
and C. There is also a substantial difference between modules of ACM and MAD. 

To better understand the relationship let us consider the ACM theory motion 
and the system description travel from Section 3.2 and represent them in 


Example 12 {A MAD Version of the System Description travel) 

The ACM system description travel is formed by the theory motion and the struc¬ 
ture Bob mnd-John. The theory consists of two modules, moving and carrying-things, 
organized into a module hierarchy in which the latter module depends on the for¬ 
mer. Let us start with the MAD representation of ACMA module moving. 

In general, the representation of an ACM module M in MAD consists of two 
parts: the declaration of sorts of M and their inclusion relation, and the collection of 
MAD modules corresponding to M. (In our first example a module of ACM will be 


Although the “Monkey and Banana” problem presented in Section 4.1 has been encoded in 
MAD as well ( [Erdogan 2008[ l, we are not considering it here because of the length of its repre¬ 
sentation and, most importantly, because there are substantial differences in how the problem 
was addressed in AC^A versus MAD from the knowledge representation point of view. 
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mapped into a single module of MAD.) Note that sorts can also be declared within 
the module but in this case they will be local (i.e., invisible to other modules). 
Declarations given outside of a module can be viewed as global. 

In our case, the sorts and inclusions sections of the translation 
Ml = MAD{moving) consist of the following statements (We remind the reader that 
in MAD variables are identifiers starting with a lower-case letter and constants are 
identifiers starting with an upper-case letter, the opposite of ACM. ): 

sorts 

Universe; Points; Things; Agents; 
inclusions 
Points <C Universe; 

Things <C Universe; 

Agents <C Things; 

The sorts part declares the sort universe (which is pre-defined and does not require 
declaration in ACM) together with the sorts of moving that are not special cases 
of actions. The inclusions part describes the specialization relations between these 
sorts. The definition of a MAD module starts with a title: 


module Mi 


The body of a MAD module consists of separate (optional) sections for the declara¬ 
tions of sorts specific to the current module, objects, fluents, actions, and variables, 
in this order, together with a section dedicated to axioms (Erdogan 20081. Our 
module Mi starts with the declarations of fluents: 


fluents 

Symmetric-Connectivity : rigid; 

Transitive-Connectivity : rigid; 

Connected {Points, Points) : simple; 
Loc-in{Things) : simple (Points); 

Rigid fluents of MAD are basic statics of ACM. 


To declare the action class move of moving we need to model its attributes. To 
do that we introduce variables with the same names as the associated attributes 
in moving. This will facilitate referring to those attributes later in axioms. We 
also order attributes alphabetically as arguments of the action term to ease the 
translation of special case action classes of move: 

actions 

Move{Agents, Points, Points); 

The variable declaration and axiom part come next. We will need to add extra 
axioms (and associated variables) to say that Loc-in is an inertial fluent (i.e., basic 
fluent in ACM terminology) and that Move{Agents, Points, Points) is an exoge¬ 
nous action (i.e., it does not need a cause in order to occur; it may or may not 
occur at any point in time). 
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variables 

ii, ^2 : Things; 
actor : Agents; 
origin, dest : Points; 

axioms 

inertial LocAn{t); 

exogenous Move{actor, dest, origin); 

The causal law for move can now be expressed in a natural way: 

Move{actor, dest, origin) causes LocAn{actor) = dest; 

Similarly for the executability conditions: 

nonexecutable Move{actor, dest, origin) if LocAn{actor) ^ origin; 

nonexecutable Move{actor, dest, origin) if LocAn{actor) = dest; 

nonexecutable Move{actor, dest, origin) if LocAn{actor) = origin, 

-^Connected{origin, dest); 

The situation becomes substantially more difficult for the definition of Connected. 
The definition used in moving is recursive and therefore cannot be easily emu¬ 
lated by MADA causal laws. The relation can, of course, be explicitly specified 
later together with the description of particular places, but this causes considerable 
inconvenience. 

To represent module carrying-things from the theory motion we need a new 
(global) sort: 

sorts 

Carriables; 

inclusions 

Carriables Things; 

The module M 2 that corresponds to carrying-things contains declarations of the 
new action Carry and the corresponding variables. 

module M 2 ; 
actions 

Carry{Agents, Carriables, Points, Points); 
variables 
t : Things; 
actor : Agents; 
dest, origin, p : Points; 
carried-object, c : Carriables; 

Next we need to define axioms of the module. Clearly we need to say that the action 
Carry{actor, carried-object, dest, origin) is a special case of the action 
Move{actor, dest, origin). Since ACAi allows action sorts, no new mechanism is 
required to do that in carrying-things. In MAD, while there is a built-in sort ac¬ 
tion, special case actions are not sorts and the special constructs import and is are 
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introduced to achieve this goal. Special case actions are declared in MAD by im¬ 
porting the module containing the original action and renaming the original action 
as the special case action as follows: 

import Ml] 

Move{actor, dest, origin) is Carry {actor, carried ^object, dest, origin); 

Intuitively, this import statement says that the action Carry{actor, carried-object, 
dest, origin) has all properties that are postulated for the action Move{actor, dest, 
origin) in the module Mi. We also need an additional axiom declaring the action to 
be exogenous, and state constraints, and executability conditions similar to those 
in carrying-things: 

axioms 

exogenous Carry{actor, carried-object, dest, origin); 

% State constraints: 

Is-held{c) if Holding{t, c); 

% Executability conditions: 

nonexecutable Carry {actor, carried-object, dest, origin) if 
-^Holding{actor, carried-object); 

nonexecutable Move{actor, dest, origin) if Is-held{actor); 

Note, however, that the ACM. module carrying-things also contained the recursive 
state constraints below, saying that agents and the objects they are holding have 
the same location: 

loc-in{C) = P if holding{T, C), loc-in{T) = P- 

loc-in{T) = P if holding{T, C), loc-in{C) = P- 

Since this is not allowed in MAD, we have to use a less elaboration tolerant repre¬ 
sentation by adding an explicit causal law saying 

Move{actor, dest, origin) causes Loc-in{c) = dest if Holding {actor, c); 

In MAD additional axioms will be needed to rule out certain initial situations 
(e.g., “John is holding his suitcase. He is in Paris. His suitcase is in Rome.”) or to 
represent and reason correctly about more complex scenarios (e.g., “Alice is in the 
kitchen, holding her baby who is holding a toy. Alice goes to the living room.”). 

This completes the construction of M 2 . 

In general, special case actions are declared in MAD by importing the mod¬ 
ule containing the original action and renaming the original action as the special 
case action. That is why we needed to place the MAD representation of carry in 
a new module that we call M 2 , in which we import module Mi while renaming 
Move{actor, dest, origin) as Garry {actor, carried-object, dest, origin). In ACM the 
declarations of move and its specialization carry could be placed in the same mod¬ 
ule - the decision is up to the user - whereas in MAD they must be placed in 
separate modules. This potentially leads to a larger number of smaller modules in 
MAD than in ACM representations. 

Finally, we consider the structure of our ACM system description. It contains 
two types of actions go{Actor, Dest) and go{Actor, Dest, Origin). Let us expand the 
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structure by a new object, suitcase, and a new action carry{Actor, suitcase, Best). 
For illustrative purposes, let us assume that we would like the MAD representation 
to preserve these names. 

To represent this in MAD, we introduce a new module S. It has the local defini¬ 
tions of objects: 

module S; 
objects 

John, Bob : Agents] 

New-York, Paris, Rome : Points] 

Suitcase : Carriables] 

and those of actions. The latter can be defined via the renaming mechanism of 
MAD. This requires importing the modules in which the action classes were de¬ 
clared. Thus, module S imports modules Mi and M 2 . 

actions 

Go{Agents, Points)] 

Go{Agents, Points, Points)] 

Garry [Agents, Garriables, Points)] 

variables 

actor : Agents] 
origin, dest : Points] 

import Ml] 

Move[actor, dest, origin) is Go[actor, dest, origin)] 

import Ml] 

Move[actor, dest, origin) is Go[actor, dest)] 

import M 2 ] 

Garry[actor, Suitcase, dest, origin) is Garry[actor, Suitcase, dest) 

This completes the construction of the MAD representation of the system descrip¬ 
tion travel. 


Even this simple example allows to illustrate some important differences between 
ACM and MAD. Here is a short summary: 

• Recursive definitions 

The representation of state constraints of an ACM system description is not 
straightforward if the set of state constraints defines a cyclic fluent dependency 


graph (Gelfond and Lifschitz 20121. For instance, the ACM state constraint: 

p if p- 


is not equivalent to the same axiom in MAD. The ACM axiom can be elim¬ 
inated without modifying the meaning of the system description; it says that 
“in every state in which p holds, p must hold.” Eliminating the same axiom 
from a MAD action description would not produce an equivalent action de¬ 
scription; in MAD, the axiom says that “p holds by default.” This difference 
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between ACMi and MAD is inherited from the similar difference between AC 
and C. 

• Separation of Sorts and Instances 

One of the most important features of ACM is its support for a clear separa¬ 
tion of the definition of sorts of objects of the domain (given in the system’s 
theory) from the definition of instances of these sorts (given by the system’s 
structure). Even though it may be tempting to view the first two modules, 
Ml and M 2 above as a MAD counterpart of the ACM theory motion, the 
analogy does not hold. Unlike ACM where the corresponding theory has a 
clear semantics independent of that of the structure, no such semantics exists 
in MAD. Modules Mi and M 2 only acquire their meaning after the addi¬ 
tion of module S that corresponds to the ACM's structure. We believe that 
the existence of the independent semantics of ACM theories facilitates the 
stepwise development and testing of the knowledge base and improves their 
elaboration tolerance. 

• Action Sorts 

In ACM, the pre-defined sort actions is part of the sort hierarchy, whereas in 
MAD actions are not considered sorts. Instead, MAD has special constructs 
import and is (also known as bridge rules), which are used to define actions 
as special cases of other actions. No such special constructs are needed in 
ACM. 

Moreover, in ACM, an action class and its specialization can be part of the 
same module. This is not the case in MAD where a special case of an action 
class must be declared in a separate module by importing the module contain¬ 
ing the original action class and using renaming clauses. As a consequence, 
the MAD representation of ACM system descriptions will generally contain 
more modules that are smaller in size than the ACM counterpart. On the 
other hand, note that ACM modules are not required to be large; they can 
be as small as a user desires. 

ACM allows the definition of fluents on (or ranging over) specific action 
classes only, and not necessarily the whole pre-defined actions sort, for in¬ 
stance: 

intended : agent-actions —)■ booleans 

where agent-actions is a special case of actions. There is no equivalent concept 
in MAD, where fluents must be defined on, and range over, either primitive 
sorts or the built-in sort action, but not specific actions. 

• Variable Declarations 

In ACM, we do not define the sorts of variables used in the axioms. This 
information is evident from the atoms in which they appear. In MAD, vari¬ 
ables need to be defined, which may lead to larger modules and cause errors 
related to use of variables of wrong types. 

• Renaming Feature of MAD 

In MAD, sorts can be renamed by importing the module containing the orig¬ 
inal declaration of a sort and using a renaming clause. The meaning of such a 
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renaming clause is that the two sorts are synonyms. There is no straightfor¬ 
ward way to define this synonymy in ACM. The closest thing is to use the 
specialization construct of our language and declare the new sort as a special 
case of the original one. The reverse (i.e., the original sort being a special 
case of the renamed sort) cannot be added, as sort hierarchies of ACM are 
required to be DAGs. This leads to further problems when the renamed sorts 
appear as attributes in renamed actions of MAD. 

• Axioms of MAD that have no equivalent in ACM 

Some axioms, allowed in MAD, are not directly expressible in ACM. For 
instance, MAD axioms of the type: 

formula may cause formula [ if formula ] 


or 


default formula [ if formula ] [ after formula ] 

belong to this group. The first axiom allows to specify non-deterministic ef¬ 
fects of actions, while the second assignes default values to fluents (and more 
complex formulas). As discussed above, we are not yet convinced that the lat¬ 
ter type of axioms needs to be allowed in ACM. Non-determinism, however, 
is an important feature that one should be able to express in an action formal¬ 
ism. It may be added to ACM (and to AC) in a very natural manner, but it 
is not allowed in AC and the mathematical properties of “non-deterministic” 
AC were not yet investigated. Because of this we decided to add this feature 
in the next version of ACM. 


We hope that this section gives the reader some useful insight in differences be¬ 
tween ACM and MAD. We plan to extend the comparison between ACM and 
MAD in the future. Formally investigating the relationship between the two lan¬ 
guages can facilitate the translation of knowledge modules from one language to 
another, and can identify situations when one language is preferable to the other. 
Readers interested in a formal translation of system descriptions of ACM to action 
descriptions of MAD can consult (Inclezan 20121. 
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